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 archivosdocker-compose.override.{name}.ymlpersonalizados 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 simplementemysqlcomo 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 composecommand)- or v1.29+ (Use
docker-composecommand)
- or v1.29+ (Use
Setup Process
- Open a terminal or command prompt.
- Git clone the project to a path and
cdto it. If possible open the directory in an IDE. - 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
- In file
./.env, you will have to update the values per your need.COMPOSE_FILE: Mention thedocker-compose.override.{name}.ymlfiles you will want to use. Keep thedocker-compose.override.ymlfile 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.
- 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.
- Files in
.envs/{name}.env, update them as you need. - Run
docker compose pullto pull/download all the images. Sometimes it will stop due to network error, just re-run it. - Run
docker network create common-net. We will use this network to connect internally from our applications. - (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. - (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 -dor... - Run specific services only by
docker compose up -d <service1> <service2> ...- Ex.
docker compose up -d adminer mysql
- Ex.
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 downor... - Stop specific services only by
docker compose rm -sf <service1> <service2> ...- Ex.
docker compose rm -sf adminer mysql
- Ex.
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