It's awesome that Auto Deploy deploys a Docker image automatically for a project, but the configuration of services and ingress is hard-coded. We should let developers customize how their apps are deployed, yet still take advantage of the rest Auto Deploy has to offer.
- If project has Helm chart (
./chart/Chart.yaml) or has variable pointing to a chart (
AUTO_DEPLOY_CHART), use it
- If project has
docker-compose-bundle.dab, use it to derive k8s config (using Kompose?)
- If project has
docker-compose.yml, use it to derive k8s config (using Kompose?)
- If project has
Dockerfile, use it, with default k8s config (ideal from Helm chart, but currently from parametrized YML)
- If nothing, use Herokuish buildpacks to create Docker image, and default k8s config to deploy
Going further, ideally Auto Deploy would add a default helm chart to your project's repo for you, so you have a place to start for edits and incremental learning.
Links / references
- May build on #30723 option 2.
Auto Deploy deploys a Docker image automatically for a project, including automatic configuration of a good CI/CD pipeline. But the configuration of services and ingress is hard-coded and if you want something custom, you have to give up the rest of the benefits of Auto Deploy.
GitLab 9.2 adds support for leveraging Helm Charts when using Auto Deploy. Simply create a project-level variable
CI_AUTO_DEPLOY_CHART to point to a Helm chart, this will now be used for deployment rather than the built-in chart. The value can be a reference to a stable chart, a full URL for another chart, or even a filesystem path to a chart embedded in your project repo.
Thinking more about this, perhaps we could let people specify a URL to a helm chart rather than requiring them to include the files in their project repo. In the variable, they could still point to a directory in their repo if they want (e.g.
./chart), but this lets them point to an external URL instead, or even a stable helm chart. We won't likely support charts in private repos this way though, but perhaps that could be a future iteration if their charts are in other GitLab projects.
Bundling a chart with the project isn't a good idea. Individual containers are building blocks of charts, there isn't a one-to-one relationship, and dynamic application configuration shouldn't be stored with the application (it defeats the purpose). Charts should be stored separately and supported in the CI/CD pipeline.
@ashernevins Yes, those are all great, valid points. Yet despite that, a lot of developers choose the experience of having the chart in the same repo. Maybe it only works for "simple" configurations. Or maybe for systems with multiple services, there's still a project responsible for deploying them all, and the helm chart could be in that project.
I also think we can move some of that dynamic configuration to project variables, such as scale (number of replicas). And then some of the deploy configuration kinda fits in the repo, if you squint just right.
I have wondered if we should have some kind of official adjust repo, just for deploy configuration. Kind of like wikis and snippets can be associated with a project, and are still version controlled, but outside of the project's main repo. Just a thought.