Containers guide
Last updated
Was this helpful?
Last updated
Was this helpful?
By now you should have a good understanding of which services (and repositories) are required to successfully model your services in Release. For each of these services, we recommend running through the following steps:
Create a Dockerfile to create a container.
Create a docker-compose to run the container.
OR
Create an Application Template file and an Environment Variables Template file in your repository.
Every application is different, so we cannot give you pre-canned files to use. However, in this guide we will walk you through using containers with Release at a high level.
In Release, services that are not static need to be run in containers. This means writing a , a set of instructions on how to build your service within a container. Here are some resources to help you write a Dockerfile:
For the best experience, your containers should be isolated and configurable.
A container should contain everything it needs to run. This means that it should not be necessary to mount files from your local filesystem into the container to make it work. You need to be able to bring up a container with no reference to local files, so that everything required is built inside the container.
In Release, you’ll use the same container image in multiple environments. For this reason, you need to be able to pass in configuration information, for example, the hostname of the generated database to use.
Traditionally, this configuration is done through environment variables, key value pairs set within a UNIX shell. An example of this might be:
Release supports environment variables as the primary way to pass in configuration information. Some frameworks and systems will automatically look for and apply environment variables, but in some cases you may have to:
Change your source code to look for environment variables and fall back to defaults if not found.
Write an /entrypoint.sh wrapper script that runs whenever your container starts, which will write any required configuration files to the container and start your service.
Secrets should never be checked into your source control (except in rare cases where you can encrypt them securely). Release offers a powerful way to input secrets into your Environment Variables Template, and this ensures that secrets are encrypted at rest and in flight during setup.
Alternatively, since Release runs in your own cloud provider account, you can also write code to integrate with your cloud-native services secrets manager, or use an open-source or managed service such as Vault.
Sometimes your code needs to behave differently depending on where its running. For example, you may want to test your email sending functionality in your test environment, but not actually email all your users whenever you run tests. Your code might therefore need to be aware of its surroundings, and adapt at execution time. But there is no single set of rules for when or how your application needs to adapt to its environment.
One final tip: If you’re using an off-the-shelf framework such as Django, Rails, or Next.js, someone has already solved every problem you will ever encounter in Docker. You can google your way out of almost any common issue!
Once you have a working Dockerfile, the next step is to build a docker-compose file. This is a built-in orchestration tool provided by Docker, and it allows you to model out multiple containers to be brought up in a specific order. A typical example would be a Django backend that requires Redis and Postgres to operate properly.
In our Django backend example, you would define the dependencies and provide the environment variables in your docker-compose.yaml file.
Here are some tutorials that will help you create a docker-compose file:
When you create an application with Release, we'll scan your Git repository for a docker-compose file and automatically model out the services it defines.
In the same way containers built from your Dockerfile must be isolated, your final docker-compose configuration must be completely self-contained and not require the mounting of files or import of anything external.
If you are an advanced user, or you are already familiar with Release, you can create or copy an Application Template and an Environment Variables Template into your repository and Release will automatically pull those files in during the scan process. If you have GitOps enabled, the whole process will be completely automated on every check-in of your codebase too. You can read more about in our documentation.