Container manager

An experimental repo to explore container management of docker containers as an alternative or supplement to systemd services.

In short this repo seeks to take full advantage of the statelessness of containerized systems. By wrapping applications in containers incrementing versions should be trivial, regardless of which versions a system has run before. It should also give added bonuses in terms of logging and transparency in terms of which containers have access to which devices. Finally it offers modification of application arguments and clean restarts in a handy manner and also hides away the docker daemon from malicious users.

Getting started:

1. Ensure you have installed docker, see: https://docs.docker.com/engine/install/ubuntu/
2. Build the proof-of-concept images, and manager backend and frontend applications using SYS_VER=image_v0.0.5 docker compose build
3. Start up the manager-api and manager-web applications in the background using ? docker compose up manager-api manager-web -d
4. Navigate to localhost:5000

Work notes:

Basic use:

Build images: docker compose build arg-poc Run specific image: docker compose up arg-poc Run all images: docker compose up

Integration with github actions

• if branch is tagged to match regex: image_v[0-9]+.[0-9]+.[0-9]+, start deploy image pipeline, regarding tag naming, see conventions: https://docs.docker.com/engine/reference/commandline/tag/ So to tag and create images from ci, use:

    git tag -a image_v0.0.1 -m "example tag to trigger build"
    git push origin <tag_name>

Pulling generated images with specific version from repository

Given that they have been generated by the ci, as specified by tag above it should be possible to pull images by:

SYS_VER=0.0.1 docker compose pull

Regarding image size etc., docker is excellent at layered pulls, that means it will reuse most of the parts of the images pulled. So at the initial pull alpine is around 700MB for one image, after that it's much smaller.

Pushing a local repository to docker registry manually

    docker login --username username
    docker tag my-image username/my-repo
    docker push username/my-repo

Pushing a specific image to docker registry manually

    docker build -t appname -f dockerfilepath/Dockerfile .
    docker login --username username
    docker tag appname username/registryname:tagname
    docker push username/registryname:tagname

Pulling a specific tag from docker registry

    docker login --username username
    docker pull stianlaa/dev-docker-repo:first-tag

Authentication

There might be an alternative to do docker login upon setup. Docker login creates or updates the ~/.docker/config.json file for you.

Management api

• api to manage services (e.g. for management from web)
• maybe there are node modules which provide the integration out-of-the-box Node packages to interact with docker:
• https://www.npmjs.com/package/dockerode
• https://www.npmjs.com/package/node-docker-api

Removing unknown containers, (permission issue)

Removing unknown containers

sudo aa-remove-unknown
docker container kill $(docker ps -q)

Stopping running rust apps

Rust doesn't automatically handle sigterm signal, docker by default emits sigkill which works after 10 seconds
To emit sigkill with a shorter delay, --time option can be used
docker stop <container> --time=1

Regarding manager implementation

It seems that docker daemon communications ideally over socket, and a webserver should exist to map and forward http requests, much the same way a systemd setup might have to. It is possible to expose the docker daemon, but not recommended, and this would entail extra work in frontend: https://towardsaws.com/ec2-2-ways-to-expose-docker-daemon-to-the-internet-why-61e349f99744

Remaining to explore:

• replace compose and sub objects with own object
• make api casing consistent
• consider how SYS_VER might best be set
• make tests, look into integration tests, mocking away dockerworker
  • read example compose file, serialize it, (with camelCase)
• fix refreshing on containerpage
• consider protecting some containers from being stopped from frontend
• make example app which uses camera
• make example app testing logging capability
• make example apps which interact over network

---

docker-compose plan: endpoints, naming and structure:

structure:

• what is running is containers, and should be named so, to distinguish them from systemd services
• instead of integrating directly with docker-compose, introduce endpoint for list of containers, this allows for docker changes in the future without adapting frontend
• similarly, keep mapping layer between docker-api and docker endpoint