-
Notifications
You must be signed in to change notification settings - Fork 65
Docker Compose Support
Docker Compose is a tool that lets you define complex multi-container applications in YAML formatted text files (usually named docker-compose.yml) and then deploy these application with a single simple command:
docker-compose upIn the docker-compose file it is possible to define multiple services (containers) with their specific properties (e.g. volume mounts port mappings, links, etc.). Is is also possible to specify a Docker file that defines how to build specific images that cannot be found in existing registries.
It is possible to import docker-compose templates in Admiral by navigating to the templates view and clicking on the "Import template or Docker Compose" button.
You will be prompted to either to upload the docker-compose template or to enter its contents yourself. Both options lead to the same result - after pressing the import button, the docker-compose is converted to a template and stored in Admiral. However, the current version of Admiral started its development when there was no networking in Docker. Since networking is now the recommended way to provide means of communication between containers, most of the docker-compose files that one may find on the Internet (e.g. in Docker hub containers' documentation) need some slight modifications to work correctly in Admiral. In the following sections the differences between standard and Admiral supported docker-compose files will be discussed.
In all of the following, only Docker Compose file format version 2 is considered.
This means that the following are currently not going to work:
- Define environment variables in separate .env file
- Splitting docker-compose file in separate files that extend one another
- Other similar use-cases
In Docker Compose there is an option to specify instructions on how to build a specific image that cannot be found in existing registries by using the build key. In the simplest case, the value of this key is the path to the build context (e.g. directory that contains a Dockerfile). In Admiral building images is not possible as this feature makes more sense for development and testing purposes. The recommended way to deal with compose files the build key is to actually build the images and push them to a registry that is accessible from all Docker hosts.
Thus, features like the network_mode and networks keys that were introduced in the Docker Compose file format version 2 will not work. However, the newly added multi-host container communication Docker feature comes out of the box with Admiral. It is possible, for example, to have a front-end container that runs on host1 and connects to a database that runs on host2.
Since file format version 2, Docker Compose Networking was introduced. Basically, for each application that is defined by a docker-compose file, a new network is created. All of the services (containers) of this application join this network. These services are all accessible and can all be discovered on hostnames that match the service name (e.g. service1 can talk to service2 by connecting to 'service2'). This means that all container ports that are exposed by the EXPOSE command in the corresponding Docker files are now accessible by all services in the application without the need of using the links and ports keys in the docker-compose file. However, Admiral 0.5 does not support docker networking and instead provides its own solution for inter-container communication that is based on proxying the communication through a system container. This will work correctly only if:
- all container2container dependencies are explicitly declared with the links key (so the system container will know which other containers to allow to communicate with one another)
- all exposed ports of containers are declared with the ports key (so the system container knows what routing rules to apply)
- here is a feature in Admiral - consider containers A and B. B listens on container port X and wants to connect to B. In Admiral it is possible to map X to a random host port but have A connect to B on port X. This is accomplished by the system container that listens on port X and relays the communication to the right port on B.
Publishing port X of container C to the same host port X is possible, but may lead to unwanted behavior of applications. With the current networking implementation, this action will result in the container C and the system container (cmp_agent_core) trying to listen on the same port X. This is a known issue and will be fixed with the upcomming networking improvements. Until then, please refrain from publishing container port to the host port with the same number. You could chose an arbitary host port that does not coincide with any container port or let Bellevue automatically chose a free host port.
The current Wordpress docker-compose template can be found on https://hub.docker.com/_/wordpress/:
version: '2'
services:
wordpress:
image: wordpress
ports:
- 8080:80
environment:
WORDPRESS_DB_PASSWORD: example
mysql:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: example