App of apps pattern for Docker

The GitOps approach is a very appealing method for the deployment of the applications. It provides a clean way to maintain configuration, versions, and deployment using git as a source of the truth. Docker itself doesn't provide a method for achieving this.

When you use Docker Compose or Docker Swarm you need to apply definition files yourself.

Doing docker-compose limits the usage most often to the developer's local environment since maintaining it for complex projects is a little bit trickier.

Inspired by Kubernetes and ArgoCD, simplecontainer provides the functionalities of declarative definitions, reconciliation, and GitOps for the containers currently only running under the Docker daemon.

Why simplecontainer?

Often deploying internal company tools, simple blogs, single host applications and other software which uses doesn't justify the high expenses and complex onboard of the running Kubernetes cluster are stuck to some variations of glue scripts to build and deploy software on the virtual machines.

The on-prem software for maintenance of the deployments of the container is available but offerings are limited since no one cares about those.

The simplecontainer provides a declarative way of defining:

• Containers
• GitOps
• Network
• Resource
• Configuration
• And other resources..

The simplecontainer runs as a container itself with given access to the Docker socket. Definition files received by the simplecontainer are reconciled to the Docker daemon via the socket itself.

You can see more at the simplecontainer site itself.

Installing simplecontainer

To install simplecontainer follow the Quick Start tutorial:

Process is straightforward, just follow the instructions in the article.

App of apps pattern for Docker containers

Following the examples in the https://github.com/simplecontainer/examples/tree/main/tests/gitops we will demonstrate how to implement GitOps design using only Docker as the platform.

git clone https://github.com/simplecontainer/examples
cd examples

Now there are multiple directories. Let's inspect /tests/gitops/

Inside there are:

• apps/gitops-plain.yaml
• apps/gitops-auto.yaml
• app-of-apps.yaml

Let's inspect the file apps/app-of-apps.yaml.

kind: gitops
meta:
  group: examples
  name: app-of-apps
spec:
  repoURL: "https://github.com/simplecontainer/examples"
  revision: "main"
  directoryPath: "tests/gitops/apps"

Applying this file, simplecontainer will receive the GitOps object and will reconcile the definition to the state defined.

smr gitops list
GROUP     NAME         REPOSITORY                                             REVISION  SYNCED        AUTO   STATE    
examples  app-of-apps  https://github.com/simplecontainer/examples (cb849c3)  main      Never synced  false  Drifted  

smr gitops sync examples app-of-apps
sync is triggered manually

smr gitops list
GROUP     NAME          REPOSITORY                                             REVISION  SYNCED        AUTO   STATE    
examples  app-of-apps   https://github.com/simplecontainer/examples (cb849c3)  main      cb849c3       false  InSync   
examples  plain-auto    https://github.com/simplecontainer/examples (cb849c3)  main      cb849c3       true   InSync   
examples  plain-manual  https://github.com/simplecontainer/examples (cb849c3)  main      Never synced  false  Drifted  

As we can see there is a parent GitOps object called app-of-apps that will create other GitOps objects defined in the apps subdirectory. This popular pattern is called app of apps pattern, coined term by ArgoCD.

Since GitOps plain-auto will do auto sync the containers will be created.

Running the smr ps will print out the containers which are managed by the simplecontainer and the state of those.

smr ps
GROUP    NAME     DOCKER NAME        IMAGE           IP  PORTS  DEPS  DOCKER STATE  SMR STATE         
example  busybox  example-busybox-1  busybox:latest                   running       running (24m49s)  
example  busybox  example-busybox-2  busybox:latest                   running       running (24m49s) 

Objects defined in the /tests/minimal are reconciled the definition to the Docker daemon, since busybox containers are running.

If you execute docker ps on the same host where simplecontainer is running you will get the state of the running containers.

docker ps
CONTAINER ID   IMAGE            COMMAND                CREATED             STATUS             PORTS                    NAMES
509e02877b72   busybox:latest   "sleep 3600"           26 minutes ago      Up 26 minutes                               example-busybox-2
a17f9f7b8761   busybox:latest   "sleep 3600"           26 minutes ago      Up 26 minutes                               example-busybox-1
9387c7b303f2   smr:137fdf4      "/opt/smr/smr start"   About an hour ago   Up About an hour   0.0.0.0:1443->1443/tcp   smr-agent

We can see that simplecontainer is running and busybox containers.

It is pretty easy to implement gitops apporach for the deployment of the Docker containers and other accompanying objects - which you can read more about those objects at the simplecontainer.qdnqn.com.