Docker was born for the cloud. It is the easiest way to run different software in a tiny box, installing it in a rapid way and with a nice way to wipe it in a snap.
But when docker shines are the little docker compose files, which realize the Infrastructure as Code, a configuration file which declare in an easy and simple way how services are connected.
After learning docker, playing with “docker run/exec/compose/swarm” and so on, you could be rightly confused. So my suggestion is to start to use docker in a “docker-compose” way. Every time you need to do something, even a simple test, fire your visual studio code and write down a docker compose file.
A good docker-compose setup take care of
- Allocating volumes
- Mapping right ports
As a general rule, your docker-compose should be able to be resilient to docker-compose up & down commands.
docker-compose down normally destroys volumes.
Example1: JBoss Business Process Manager
jBPM is a complex beast with only two components: the server and the database. The server keep its workspace in a .niogit folder. This folder is normally created under the working directory the server is started.
version: '2' volumes: postgres_data: # GG: It should not destroy it if external external: name: jbpm_pgsql_data jbpm_git: external: name: jbpm_git services: postgres: image: postgres:9.6 volumes: - postgres_data:/var/lib/postgresql/data environment: POSTGRES_DB: jbpm POSTGRES_USER: jbpm POSTGRES_PASSWORD: jbpm jbpm: image: jboss/jbpm-server-full:7.29.0.Final volumes: - jbpm_git:/opt/jboss/wildfly/bin/.niogit environment: JBPM_DB_DRIVER: postgres JBPM_DB_HOST: postgres ports: - 8080:8080 - 8001:8001 depends_on: - postgres
Also you do not want the database be wiped out after a docker-compose down. So you set it up as an “external volume” and is up to you to create it before running docker-compose up.
Example2: Grafana + InfluxDB monitoring
The resulting docker compose can be summarized like this:
version: '3.3' services: telegraf: image: telegraf:1.3 networks: - tig-net volumes: - /var/run/docker.sock:/var/run/docker.sock configs: - source: telegraf-config target: /etc/telegraf/telegraf.conf deploy: restart_policy: condition: on-failure mode: global resources: limits: cpus: "0.5" influxdb: image: influxdb:1.2 networks: - tig-net deploy: restart_policy: condition: on-failure placement: constraints: - node.role == worker environment: - INFLUXDB_ADMIN_ENABLED=true - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin ports: # Admin - "8083:8083" # HTTP API port - "8086:8086" volumes: - influxdb:/var/lib/influxdb # Grafana grafana: container_name: grafana image: grafana/grafana:4.3.2 ports: - "3000:3000" networks: - tig-net deploy: restart_policy: condition: on-failure placement: constraints: - node.role == manager volumes: - grafana-storage:/var/lib/grafana configs: telegraf-config: file: $PWD/config/telegraf/telegraf.conf networks: tig-net: driver: overlay volumes: influxdb: grafana-storage:
This file is a bit more complex because ask to store grafana on the manager, and the influxdb on the workers
If you need to switch to a more mature setup, you can use kompose to migrate your file to the K8s fanfare.
Docker is a good starting point because of its history. Also it is fast to set up on a Windows Machine, and its faster.
K8s is your way to go in production, and its knowledge will be mandatory for the short term future.