search

nebari-dev / governance

✨ Governance-related work for Nebari-dev
BSD 3-Clause "New" or "Revised" License
0 stars 2 forks source link

RFD - Support gitops staging/development/production deployments #41

Closed costrouc closed 1 year ago

costrouc commented 1 year ago
Status Declined ❌
Author(s) @costrouc
Date Created 12/08/2023
Date Last updated 12/08/2023
Decision deadline 30/08/2023

Title

Support gitops staging/development/production deployments

Summary

This RFD is constructed from issue https://github.com/nebari-dev/nebari/issues/924. We need to have the ability to easily deploy several nebari clusters to respresent dev/staging/production etc within a gitops model. Whatever solution we adopt it should be backwards compatible and easy to adopt.

User benefit

There are several benifits:

Design Proposal

I propose using folders for the different nebari deployments. The current folder structure is:

.github/workflows/nebari-ops.yaml
stages/...
nebari-config.yaml

For backwards compatibility we keep this structure and add new namespaced ones based on the filename extension.

For example nebari-config.dev.yaml would imply the following files are written

.github/workflows/nebari-ops.dev.yaml
dev/stages/...

The github/gitlab workflows will be templated to watch and trigger only on updates to the specific files for that environment. This approach is independent of git branching.

Alternatives or approaches considered (if any)

Best practices

This would provide an easy way for users to have different deployments on the same git repository.

User impact

This change would not affect any existing nebari deployments as far as I am aware and would be backwards compatible.

Unresolved questions

Gitlab doesn't support multiple files for CI it wants a single entrypoint .gitlab-ci.yml. Pipelines would allow us to do this but then the separate stages will have to all write to the same gitlab-ci.yml file. This is solvable.

pavithraes commented 1 year ago

@nebari-dev/core-team - Please take a look and share your thoughts over the coming days, so we can decide in the team meeting on Tuesday the 22nd of August. :)

iameskild commented 1 year ago

I know we had a discussion around trying to deploy a dev and prod Nebari cluster into a single kubernetes cluster but I would recommend against that. Nebari deploys cloud resources that, if modified, can potentially impact the entire cluster which could take down the production environment.

So two distinct clusters, deployed in a gitops manner. As I see it, it might be as simple as writing a workflow that copies over the production nebari-config.yaml into a separate folder (as Chris mentioned), modify the name/namespace and deploy. It might also be worth tying in a way to delete the dev cluster after the team has tested it.

costrouc commented 1 year ago

@iameskild I believe that the discussion about multiple deployment using the same Kubernetes cluster is out of scope for this RFD. This should be addressed in a separate issue as something that nebari in general need to support.

An issue we agreed that should be included in this is a reliable destroy github/gitlab actions workflow https://github.com/nebari-dev/nebari/issues/1680

pavithraes commented 1 year ago

This has been open for feedback for a while, we'll discuss and vote on this in today's Nebari community meeting.

pavithraes commented 1 year ago

On discussion, we realized this is a documentation issue. The current setup with different repos for dev/staging/prod works with the most flexibility, but needs to be documented to be useful for more folks. @pavithraes Will open the docs issue, and then close this one.

RFD Resolution: Declined.

However, it was also observed that the multiple YAML workflows described here will be helpful in the case of multiple Nebari deployments using the same Kubernetes cluster - we'll track that in a new RFD.

Thank you, @costrouc for all your work creating and discussing this RFD!