Docker

To build and deploy your application in a Docker container, you don’t need to write a configuration file amverum.yaml at all. It’s enough to write Dockerfile. However, for more precise configuration, you may need the amverum.yaml file.

settings

When using a Dockerfile, the image build process is first initialized, running in a separate container with access to the Code folder. Once the build is complete, the image is uploaded to the repository (registry). After the image is successfully uploaded, the application deployment process is initialized, during which a container is created from the previously obtained image.

Important

docker-compose.yml is not supported. Only classic Dockerfile can be used.

Configuration file

For more precise configuration, you should supplement the Dockerfile with the amverum.yaml configuration file. Using the configuration file allows you to skip the build and run the application using a ready-made public image from a third-party registry. You can also specify the folder for mounting the persistent storage.

Meta section

For the Docker environment, the meta section can be omitted altogether. By default, it is assumed to be the following:

meta:
  environment: docker
  toolchain:
    name: docker

Build section

The build section supports the following parameters:

  • dockerfile: path to the Dockerfile file relative to the source code folder (without the leading slash); this is an optional parameter: if you do not specify it, Dockerfile will be searched in the following places:

    • amverum/Dockerfile

    • Dockerfile

    • docker/Dockerfile

    • deploy/Dockerfile

    • deployment/Dockerfile

  • skip: skip image building; used when running pre-built Docker images.

run section

The run section supports the following options:

  • image: the image to run instead of the built one; usually used in combination with build.skip: yes;

  • command: the command to run in the specified image; useful in combination with run.image; this is whatever is specified in the Dockerfile’s ENTRYPOINT or the Kubernetes Pod’s command, usually the command name without any options;

  • args: the options for the command specified in run.command; this is whatever is specified in the Dockerfile’s CMD or the Kubernetes Pod’s args, except that the options are specified as a regular string rather than an array;

  • persistenceMount: absolute path in the container filesystem where the persistent storage folder should be mounted; defaults to /data

  • containerPort: TCP port number that the application in the container listens to; defaults to 80.

Recipes

Custom application with non-standard port

If your application works over HTTP protocol, but uses a port number other than 80, you can configure it with the following amverum.yml file:

run:
  containerPort: 3000

Custom application with non-standard Dockerfile location

Let’s say the Dockerfile is located at myapp/amverum.dockerfile:

build:
  dockerfile: myapp/amverum.dockerfile

Ready-made Docker image

If you need to run a ready-made Docker image that either runs over HTTP or does not accept incoming connections (for example, a bot), you can skip the build phase and specify the image name directly.

As an example, consider deploying Dokuwiki (https://hub.docker.com/r/linuxserver/dokuwiki). Dokuwiki listens on port 80, so we do not need to change this setting. But the data folder needs to be mounted at the /config path. The following amverum.yml file is obtained:

build:
  skip: yes

run:
  image: lscr.io/linuxserver/dokuwiki:latest
  persistenceMount: /config

Since you don’t need anything other than the amverum.yml file, this is the only file you need to push to the git repository created for the project.

Application with a non-standard ENTRYPOINT

If you have written an application and have not specified either ENTRYPOINT or CMD in the Dockerfile, or you are using a ready-made image and want to use a different application from it than the one intended by the developer, the run.command and run.args parameters will come in handy.

As an example, consider an application in the Go language:

package main

import (
	"fmt"
	"net/http"
	"os"
)

func main() {
	var port string
	if (len(os.Args) > 2) && (os.Args[1] == "--port") {
		port = fmt.Sprintf(":%v", os.Args[2])
	} else {
		port = ":80"
	}

	http.HandleFunc("/", HelloServer)
	http.ListenAndServe(port, nil)
}

func HelloServer(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:])
}

Dockerfile for him:

FROM golang:1.19

WORKDIR /app

COPY server.go go.mod ./

RUN CGO_ENABLED=0 go build -a -installsuffix cgo -o server

FROM alpine:latest

WORKDIR /app

COPY --from=0 /app/server ./

To start the server, you need to call the command /app/server --port 8080, but for some reason this is not written in the Dockerfile. Let’s specify the launch parameters in amverum.yml:

run:
  command: /app/server
  args: --port 8080
  containerPort: 8080