1

Many projects need more than a Dockerfile or a docker-compose.yml in their root to work out of the box (e.g. for local development or a demo): For example a web application might need its runtime, a web server and a database, each one configured for the application. Are there already "best practices" or at least common conventions of where to put the configuration files? I've seen directory names like docker or .docker. What are good approaches and why?

  • "a web application might need its runtime, a web server and a database, each one configured for the application" I'm sorry, but isn't the precisely what Docker compose is for?? – RubberDuck Oct 5 '17 at 0:50
  • The docker-compose.yml file often references configuration files/directories for each service, which are either included as volumes or integrated via COPY inside each Dockerfile. This question is about where to best place the configuration files. – chiborg Oct 5 '17 at 17:03
  • Ideally, you want to keep apart building and assembly from deployment. The process of building and packaging the source code should remain always the same regardless the way we deploy it. Since building, assembly and deployment are different stages of the SDLC, it makes sense to separate respective resources, so that you can alter these stages without compromising others. It's also good to have a repository for configurations, for the very same reason. They come into play in a different stage of the SDLC – Laiv Nov 12 '18 at 8:10
1

The project directory is the recommended place:

In your project directory, create a file named Dockerfile and paste the following:

FROM python:3.4-alpine
ADD . /code
WORKDIR /code
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

The best practice is to use environment variables. For example:

COMPOSE_PROJECT_NAME=OpenTOSCA
COMPOSE_CONVERT_WINDOWS_PATHS=1
PUBLIC_HOSTNAME=container

to avoid OS specific issues with pathfinding:

It appears the volumes parameter for docker provider tries to sync using the path formatting of the host machine instead of the host_vm created to build and run the docker containers from.

and to use comments and OS specific shell scripting to abstract host system naming conventions:

container-repository:
  # volumes:
  #   - <path on host system>:/var/opentosca/repository

and to use overrides:

Info: We use the override feature of Docker Compose to provide different configurations for certain use cases.

Basic override file with common configuration settings for our environment:

_docker-compose.override.yml

Simply, make a copy and modify it to your needs:

cp _docker-compose.override.yml docker-compose.override.yml

Settings from docker-compose.override.yml are applied automatically when using docker-compose up.

References

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.