uselagoon / build-deploy-tool

Tool to generate build resources
4 stars 7 forks source link

Multiple nginx-php deployments are not supported #216

Open shreddedbacon opened 3 years ago

shreddedbacon commented 3 years ago

Currently deploying multiple nginx-php or nginx-php-persistent deployments are not supported.

The way the templates values.yaml check works here means that it isn't possible to run more than one.

The line DEPLOYMENT_SERVICETYPE=$line is populated with nginx and php in the while loop based on what is defined in the values.yaml file in the templates here

This causes the next variable DEPLOYMENT_SERVICETYPE_IMAGE_NAME to be empty, as the values used to check the map ${SERVICE_NAME}:${DEPLOYMENT_SERVICETYPE} are set to the hardcoded values of nginx or php for DEPLOYMENT_SERVICETYPE.

Example, given a docker-compose.yaml that is like this

version: '2.3'
services:
  nginx:
    build:
      context: .
      dockerfile: lagoon/nginx.dockerfile
    labels:
      lagoon.type: nginx-php
  php:
    build:
      context: .
      dockerfile: lagoon/php.dockerfile
    labels:
      lagoon.type: nginx-php
      lagoon.name: nginx

  second-nginx:
    build:
      context: .
      dockerfile: lagoon/second-nginx.dockerfile
    labels:
      lagoon.type: nginx-php
  second-php:
    build:
      context: .
      dockerfile: lagoon/second-php.dockerfile
    labels:
      lagoon.type: nginx-php
      lagoon.name: second-nginx

The variable map of MAP_DEPLOYMENT_SERVICETYPE_TO_IMAGENAME would contain the following indexes

nginx:nginx
php:php
second-nginx:second-nginx
second-php:second-php

But since the exec-kubectl-resources-with-images.sh script is sourcing the value DEPLOYMENT_SERVICETYPE from the templates values.yaml, the map lookup for second-nginx and second-php fail because it tries to look up in the map for these indexes

second-nginx:nginx
second-php:php

but they don't actually exist.

Since all of our other templates are single-container templates, this restriction doesn't exist. We should be able to support this configuration, even if it may not be ideal.

There are other issues with this too that need to be checked with how persistent volumes are used/consumed if a persistent volumes was to be shared between both of those deployments similar to how it is shared with the CLI deployment. Or if the second deployment is meant to have its own persistent volume created, separate to the other deployment.

tobybellwood commented 3 years ago

This can only be addressed when we move to common templates for all services, treating the nginx-php (and other multi-container pods) with post-template logic.