Dockerfile vs docker-compose.yml

Question

What is the relationship between Dockerfile and docker-compose.yml files?

It looks like I can create any Linux installation using the Dockerfile using the FROM , RUN ( apt-get , etc.) commands. But it doesn't seem to be much reusable (I can reuse the entire image, but the services are hard-coded and cannot be reused by other projects).

Can I use both files in new projects?

Say I want to have a regular LAMP stack:

• Linux OS ( debian:wheezy )
• Apache web server ( httpd:2.2 )
• MySQL ( mariadb )
• PHP ( php:5.6 )

works together, as on one, ordinary computer.

And in my host directory:

• volume for application source files
• Vhost configuration file
• apache logs
• persistent data in db

I prefer using official base repositories and images rather than pre-configured all-in-one ones.

What should the configuration files look like in this case?

I am using docker-compose v.1.8.1 and docker v. 1.12.3 on Ubuntu.

Answer 1

Dockerfile :

• is a Docker image recipe
• supports only portable parameters (other parameters should be specified while the container is running)

docker-compose.yaml :

• - This is a recipe for a group of running services.
• supports overriding portable parameters that were defined in the Dockerfile
• supports intolerable parameters
• supports the creation and configuration of networks and volumes.
• can also configure image assembly using build:

Usually use both together.

A Dockerfile almost always used to create custom images. Some images can be used to start services (lengthy processes), but some images can be used to start short-lived interactive processes (for example, to run unit tests).

docker-compose.yaml is useful if you want to start one or more services.

Answer 2

Docker creates an isolated machine (container). Each container contains only one process (Apache or Mysql or another); And Dockerfile defines how to create an image.

Docker compose allows you to run, link, and configure bunch containers.

In your case, apache should know "where" mysql. And mysql needs to be woken up before running the apache container.

Dockerfile defines a way to create an application image. The application image contains the application and a web browser.

 FROM apache:php5.6 ADD /src /var/www/awesome_project #add a project src code ADD /config/apache/awesome_project.conf /etc/apache2/sites-available/ # add a configuration # make any things 

Then you need to create a docker build my_app:latest . image docker build my_app:latest .

At this point you created the image and you need to run the application and link it to db

You have 2 ways to do this:

1) Own docker approach. you start the db container

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest

and after you need to run the application container (the image was previously created)

docker run --name my_app --link some-mysql:mysql -P -d my_app

at this stage we are working with the application. A bit is a simple thing because we make two long teams. If you need to copy the application to another computer, you need to execute this command exactly.

2) the way to create dockers allows you to create a configuration for running containers. It describes how to launch containers accurately.

A simple docker-compose.yml config illustrates this approach

 db: image: mysql environment: - MYSQL_USER=root - MYSQL_PASSWORD=root app: image: my_app:latest ports: - 80:80 depends_on: - db environment: # Database - DB_USER_NAME=root - DB_USER_PASSWORD=root 

This configuration allows you to run 2 containers together, links and configure them.

This is a very simple example. and the advantages of using dockers do not seem obvious, but if you have 5+ containers, it is too difficult to combine them without layout.

Answer 3

This is fundamentally about the separation of interests and an easy way to understand this, thinking in terms of what and how .

Dockerfile defines what happens inside the container.

Docker-compose.yml determines how this container runs on the host. That's why the docs say: "Services are just containers in production."

The container does not care how and where it starts, it just interests what it launches. The host does not care that it works, only how it works. For example, several copies, so much RAM, so much CPU.

Therefore, we create two separate configuration documents for each of these purposes.