docker-compose.ymlfile is used by Lagoon to:
labelsof a service definition.
docker-compose.ymlfile for Drupal:
/app, but you can add or change this if needed.
docker-composecalls them services, even though they are actually containers. Going forward we'll be calling them services, and throughout this documentation.
mariadbin the example above) is used by Lagoon as the name of the Kubernetes pod (yet another term - again, we'll be calling them services) that is generated, plus also any additional Kubernetes objects that are created based on the defined
lagoon.type, which could be things like services, routes, persistent storage, etc.
/var/lib/mysql, and puts it there automatically without any extra configuration to define that. For some situations, though, Lagoon needs your help to know where to put the persistent storage:
lagoon.persistent- The absolute path where the persistent storage should be mounted (the above example uses
/app/web/sites/default/files/which is where Drupal expects its persistent storage).
lagoon.persistent.name- Tells Lagoon to not create a new persistent storage for that service, but instead mounts the persistent storage of another defined service into this service.
lagoon.persistent.size- The size of persistent storage you require (Lagoon usually gives you minimum 5G of persistent storage, if you need more, define it here).
lagoon.persistent.class- By default Lagoon automatically assigns the right storage class for your service (like SSDs for MySQL, bulk storage for Nginx, etc.). If you need to overwrite this, you can do so here. This is highly dependent on the underlying Kubernetes/OpenShift that Lagoon runs on. Ask your Lagoon administrator about this.
docker-composeservice. For some cases, we need to put two containers inside a single pod, as these containers are so dependent on each other that they should always stay together. An example for such a situation is the PHP and Nginx containers that both contain PHP code of a web application like Drupal.
lagoon.typethat expects two services (in the example this is
nginx-php-persistentdefined on the
lagoon.nameof the second one with the first one. (in the example this is done with defining
phpcontainers are combined in a pod that will be called
phpin this case). It does this by searching for service names with the same name that are given by the type, so
nginx-php-persistentexpects one service with the name
nginxand one with
docker-compose.yml.If for any reason you want to use different names for the services, or you need for than one pod with the type
nginx-php-persistentthere is an additional label
lagoon.deployment.servicetypewhich can be used to define the actual service type.
php(but you can call them whatever you want). The
lagoon.nametells Lagoon which services go together - all of the services with the same name go together.
nginxand which one is the
phpservice, we define it via
A template describes a set of objects that can be parameterized and processed to produce a list of objects for creation by OpenShift Container Platform. A template can be processed to create anything you have permission to create within a project, for example services, build configurations, and DeploymentConfigs. A template may also define a set of labels to apply to every object defined in the template.
DeploymentConfigobject within Openshift/Kubernetes. It monitors the rollout based on this object. In some cases, the services that are defined via custom deployment need a different way of monitoring. This can be defined via
false- Will not monitor any rollouts, and will just be happy if the template applies and does not throw any errors.