Absortio

Email → Summary → Bookmark → Email

GitHub - a-h-abid/docker-commons: All common docker scripts in one place

Extracto

All common docker scripts in one place. Contribute to a-h-abid/docker-commons development by creating an account on GitHub.

Resumen

Resumen Principal

Docker Commons se presenta como una solución innovadora para la gestión centralizada de servicios comunes de desarrollo local, abordando un problema recurrente para desarrolladores que trabajan en múltiples proyectos. Su propósito principal es mitigar el consumo excesivo de recursos del sistema, como memoria y CPU, que ocurre al ejecutar instancias duplicadas de servicios esenciales (como MySQL, Redis o ElasticSearch) para cada proyecto individual. Inspirado en el proyecto LaraDock, esta iniciativa permite a los desarrolladores configurar y mantener una única colección de servicios comunes a través de scripts Docker, lo que resulta en una optimización sustancial de los recursos. La flexibilidad es clave, ya que el sistema es altamente configurable, permitiendo activar solo los servicios necesarios y gestionar sus configuraciones y versiones desde un único punto. Esto simplifica drásticamente la memorización de puertos publicados y asegura una base de desarrollo consistente, funcionando predominantemente en Linux, pero con soporte experimental para Windows a través de WSL2.

Elementos Clave

  • Optimización de Recursos y Gestión Centralizada: El proyecto resuelve la ineficiencia de correr múltiples instancias de servicios como MySQL o Redis por cada proyecto de desarrollo. Ofrece una plataforma para gestionar estos servicios de forma centralizada usando Docker, lo que reduce la carga del sistema y simplifica la administración de configuraciones y puertos, liberando recursos valiosos y eliminando la redundancia.
  • Extensa Variedad de Servicios Soportados: Docker Commons es compatible con una impresionante lista de servicios esenciales para el desarrollo. Incluye bases de datos como MySQL, Postgres, Mongo y Oracle; herramientas de cacheo como Redis y Dragonflydb; sistemas de monitoreo como Grafana y Kibana; plataformas de mensajería como RabbitMQ; y utilidades como Adminer, Mailhog, Portainer y Traefik, demostrando su versatilidad para casi cualquier stack de desarrollo.
  • Proceso de Configuración Altamente Personalizable: La configuración se gestiona mediante archivos de ejemplo (.env.example, docker-compose.override.example.yml, .envs/{name}.example.env) que deben ser copiados y adaptados. Esta aproximación permite a los usuarios seleccionar y activar solo los servicios que necesitan, modificar sus ajustes específicos e incluso integrar archivos docker-compose.override.{name}.yml personalizados para una flexibilidad máxima en la construcción del entorno.
  • Integración Fluida con Aplicaciones Locales: El diseño facilita la conexión de las aplicaciones de desarrollo a los servicios comunes. Las aplicaciones se conectan a la red common-net, utilizando los alias de red de los servicios como nombres de host. Por ejemplo, una aplicación puede conectarse a MySQL usando simplemente mysql como host, lo que simplifica la configuración de la conexión y promueve una estructura de desarrollo más limpia y eficiente.

Análisis e Implicaciones

Este enfoque centralizado mejora drásticamente la productividad del desarrollador al estandarizar el entorno local, lo que reduce el tiempo de configuración y los conflictos de servicios. Al disminuir la carga de recursos del sistema, permite a los desarrolladores ejecutar proyectos más complejos simultáneamente. Su adoptabilidad puede acelerar la integración de nuevos miembros en equipos, al proporcionar una base de servicios coherente y bien definida.

Contexto Adicional

El proyecto surge de una necesidad personal, inspirada por la eficiencia de LaraDock, con el objetivo de proporcionar una base de servicios robusta y consistente para un desarrollo de aplicaciones más ágil y eficiente.

Contenido

Docker Commons

This is a personal project which consists some common services configured to run via docker scripts to use centrally for applications in local development.

The problem this project solves is that during development in multiple projects, sometime they have their own services (MySQL, Redis, etc.) which already takes lots of resources by itself and having to run same services multiple times for multiple projects is too much for your system. Also most of the time those services configurations & versions are not much different in each project. Or those differences might not matter to you. Also keeping up with remembering all the publish ports of these services can be quite difficult.

As these things became a problem for me and also inspired by LaraDock project, I made this docker script to easily manage them centrally from one place. Also made it configurable to run only those services you need.

I have tested it mostly in a Linux environment, but I also tried to add some support for Windows OS. If your Windows OS supports WSL2, I highly encourage you to use that.

Services

Name In Compose Require Image Build Network Alias
Adminer adminer
Blackfire blackfire common-blackfire
Cassandra cassandra common-cassandra
Dragonflydb dragonfly common-dragonfly
ElasticSearch elasticsearch Yes common-elasticsearch
Flagr flagr Yes common-flagr
Grafana grafana
Jaeger jaeger common-jaeger
Jenkins jenkins common-jenkins
Kibana kibana Yes
MailDev maildev common-maildev
Mailhog mailhog common-mailhog
MinIO minio common-minio
MinIO Client (MC) minio-client
Mongo mongo common-mongo
MySQL mysql common-mysql
NFS Server nfs-server
OpenLDAP ldap common-ldap
Oracle oracle Yes common-oracle
Portainer portainer
Postgres postgres common-postgres
RabbitMQ rabbitmq common-rabbitmq
Redis redis common-redis
Redis Commander redis-commander
Redis Sentinel redis-sentinel common-redis-sentinel
RediSearch redisearch Yes common-redisearch
SFTP sftp common-sftp
Traefik traefik traefik
Volume Backup volume-backup
Volume Restore volume-restore

Note: The following services will not work in Windows Host Machine. You will have to use it inside WSL2 Distribution.

  • NFS Server

Tested Docker Version

  • Docker Engine v20.10+ / Docker Desktop v4.0+
  • Docker Compose v2.7+ (Use docker compose command)
    • or v1.29+ (Use docker-compose command)

Setup Process

  1. Open a terminal or command prompt.
  2. Git clone the project to a path and cd to it. If possible open the directory in an IDE.
  3. You will have to create files from example files. You can simply run the copy-examples.sh (Linux) / copy-examples.bat (Windows) / bash copy-examples.sh (MacOS) file to auto-create them or create them manually as below by copying them. Special note: DO NOT DELETE EXAMPLE FILES. These are kept for reference.
    • .env.example -> .env
    • docker-compose.override.example.yml -> docker-compose.override.yml
    • .envs/{name}.example.env -> .envs/{name}.env
  4. In file ./.env, you will have to update the values per your need.
    • COMPOSE_FILE: Mention the docker-compose.override.{name}.yml files you will want to use. Keep the docker-compose.override.yml file at the end. Use separator : for Linux or ; for Windows.
    • COMPOSE_PATH_SEPARATOR: Use separator : for Linux or ; for Windows.
    • Rest details are written in the file as comments. Read and do update as you need.
  5. In file ./docker-compose.override.yml, you will have to update the values per your need.
    • Remove any service sections you will not use.
    • Modify any settings you want to add or remove as you need.
  6. Files in .envs/{name}.env, update them as you need.
  7. Run docker compose pull to pull/download all the images. Sometimes it will stop due to network error, just re-run it.
  8. Run docker network create common-net. We will use this network to connect internally from our applications.
  9. (Optional) If you want to use Traefik, run docker network create common-traefik-net. We will use this network to serve web requests using domain names to our application's web server.
  10. (Optional) If you are using any of the services that require image to build, run docker compose build <service-name> to build those images.

Running Services

  • Run all services quickly by docker compose up -d or...
  • Run specific services only by docker compose up -d <service1> <service2> ...
    • Ex. docker compose up -d adminer mysql

Checking Services Status

  • Check services status by docker compose ps.
  • If need to check logs, run docker compose logs --tail=100 <service-name>.

Stoping Services

  • Stop all services quickly by docker compose down or...
  • Stop specific services only by docker compose rm -sf <service1> <service2> ...
    • Ex. docker compose rm -sf adminer mysql

General Usage in Applications

The general idea is to connect your application container network to the common-net and use that service's network alias name as host name and that service's container port number to connect to that service.

For example, lets say you want to connect to MySQL. You application's docker compose file may look something like this:

networks:
  common-net:
    external: true

services:
  myapp:
    ...
    networks:
      - common-net
      ...

And in you application database configuration:

  • Database Hostname as common-mysql
  • Database Port as 3306

Then start/restart your application container and will be connected to MySQL.

This is the general approach for most of these services to be connected with your application.

Service Specific Details

NFS server

After starting the container, you have to mount nfs server in your host machine. To get container IP, you can use ifconfig or hostname -I or any other method you know.

sudo mount -v -o vers=4,loud <container-ip>:/ /path/to/mount

Important: In your development machine, be sure to unmount the path, otherwise may cause issues. To unmount:

sudo umount /path/to/mount

FAQ

Can I run this in production?

While this is made for local development usage, it can be used in production with some caveats. There are might be some configurations that you may need to change or you may same some special case that may not be possible with current project structure. Also there are security concern that you should worry about. In that case, you will have to use your own approach to serve your need. It maybe by mounting config files in the container, using a different image or simply running a native service solution.

Future Plans

  • Make it work with Podman.

License

This project is licensed under the terms of the MIT license.

Fuente: GitHub