Smart deploy, simplify the .gitlab-ci.yml syntax by assuming Kubernetes
Description
Deploying via shell scripts is powerful in that it's incredibly flexible, but sometimes it's too cumbersome, ugly, or not functional enough. We need a higher-level construct, especially for deploys, that let's developers easily configure common deployment scenarios.
Proposal
- Introduce specific keywords for various deployment scenarios such as
kubernetes, ideally through extensible plugins (#14178). - The deploy plugin may run in the context of the GitLab rails server rather than the GitLab runner. There are various pros and cons to this.
- Running in Rails allows access to deployment variables without having to expose them to the runners.
- Running in Rails allows easier return of richer information than simple pass/fail exit code. e.g. return information needed for connecting a terminal to a container. (Runners could support this, but we'd have to extend the API)
- Plugins running in Rails might be more approachable than writing in Go.
- Either way, the plugin would be able to directly connect services via API without needing scripts or CLIs.
- Plugins could be tightly tied to Services to provide the ability to store variables or otherwise configure deployment at a project level (#23859)
- Richer interactions could allow actions beyond simple deployment such as:
- access a terminal that connects to running environments
- smart monitoring of deployments
- incremental/rolling deploys, canary deploys, blue/green deploys, traffic vectoring, etc.
- simplifying closing environments
- restart/pause/etc of environments
- The obvious downside is that this would be GitLab-specific, and up to us to maintain as things change.
review_app:
kubernetes:
pod: my/pod/file
variables:
MY_APP_DOMAIN: review-$DOMAIN.app.com
environment:
name: review/$APPLinks / references
- From #22864 (comment 16790373) and #23286 (closed)
- GitLab Runner plugins: #14178
/cc @ayufan
-
-
-
-
Edited by Warren Postma
I'm building some large and ever-larger systems in a DevOps fashion inside a healthcare software company, in a Windows centric sub-planet where the CI/CD tooling is pretty scarce and lousy. I think Gitlab CI could actually win pretty big inside the Windows world if it actually contained its own cross platform set of working integrated deployment tools. But I don't imagine that you can have ONE set of tools to rule the whole world. So I think a plugin architecture, plus a default set of built-in or easy-to-get-started-with outside tools, that works on Windows and on Linux would be great.
I agree 100% with the plugin ideas. I think plugins could exist for:
-
Windows ecosystems:
- msdeploy (windows web deployment, azure and private IIS hosting)
- octopus (windows web, desktop, and server deployments)
-
Linux CI/CD/DevOps ecosystems:
- Rich integration with simple web-deployment and post-deploy web-health-check tools for various cloud and private web hosting systems, including even smart rollbacks.
- kubernetes
- paas platforms like openshift
- iaas platforms like openstack
- Rich integration with simple web-deployment and post-deploy web-health-check tools for various cloud and private web hosting systems, including even smart rollbacks.
-
Deploying Components is as important as Deploying apps.
- Java maven repository health and management, publish, and unpublish.
- .NET NUGET Feed health and management, publish, and unpublish
- Dynamic languages (ruby, python, nodejs) and their packaging/repository technologies.
You could even change the title of this to "Smart Ops" since Deploy/Rollback and other things are all smart-operations actions, ones that can detect that something is bad or something is good, after the deploy, and perhaps even take corrective further actions when necessary.
-
-
-
-
-
changed title from Smart deploy to Smart deploy, simplify the .gitlab-ci.yml syntax by assuming Kubernetes
Toggle commit list -
-
Please register or sign in to post a comment