-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs on how to configure gitops for github-actions and gitlab-ci #280
Conversation
✅ Deploy Preview for nebari-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @costrouc ! This is a great start. I have some questions. I've also pointed out some cross-reference points that I think will help with discovery.
managing the state of your infrastructure. This allows for easy | ||
auditing and discovering the current state of your system. | ||
|
||
## Setting up IaC on Github-Actions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the title of the document is centered aroud gitops
, I would expect we would use gitops
in the headers. Or else change the title to be Setup Nebari Infrastructure as Code
GitOps also known as Infrastructure as Code(Iac) is the practice of using git for | ||
managing the state of your infrastructure. This allows for easy | ||
auditing and discovering the current state of your system. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other parts of these docs, we covered [installing Nebari](/get-started/installing-nebari) and the various [methods of deployment](/get-started/deploy) which including walking you through the creation of the central configuration file for Nebari, `nebari-config.yaml`. We can take our automation one step further by ensuring that any changes to this configuration will redeploy the entire Nebari platform via CI. This document will show you how to set things up. |
Not sure about those link paths, and I didn't spend time making the wording right, but you get the point. We need something here to say "this is the icing on the cake".
And as a sister comment... We need to link to this document at the bottom of each Deploy Nebari on ...
doc as a Next Steps
.
ci_cd: | ||
type: github-actions | ||
branch: main | ||
commit_render: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've read the whole doc and I still don't know how this works.
- after I put this in my config, what do I need to run?
- if I include this here, then run
nebari deploy
it will generate some/.github/workflow/deploy.yml
scripts for me? - What do the "appropriate workflows" look like?
- Will I need to commit them to a repo?
- When I make changes to the repo, what will happen? Is it watching all files, or only certain files?
- What step am I automating here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just added gitops to an existing Nebari deployment that was not set up initially with that functionality. We did not use the guided set-up - we deployed Nebari using a configuration file. It may be important to note that we did include this in the configuration yaml file during initial deployment (I'm not sure if a user who did not include this would have to take additional steps before the steps I took):
ci_cd:
type: github-actions
branch: main
commit_render: true
To set up gitops, I then
- created a repo and pushed all files from deployment to it (
.github
,stages
,.gitignore
,nebari-config.yaml
). - Created the following secrets for Github Actions to use:
AWS_ACCESS_KEY_ID
,AWS_SECRET_ACCESS_KEY
,REPOSITORY_ACCESS_TOKEN
with the keys/tokens that I used to deploy Nebari. - I enabled ACLs on the S3 bucket created by my Nebari deployment (named
{project_name}-dev-terraform-state
. I used my AWS console to find the bucket, clicked on the Permissions Tab, scrolled to Object Ownership and clicked edit, then selected ACLs enabled. (see here).
After taking these steps, I was able to make a change to my configuration file and open a PR. This triggered the github/workflows/nebari-linter.yaml
job. When that passed, I merged the PR, which triggered the job created by .github/workflows/nebari-ops.yaml
and the update to our deployment was successful.
|
||
|
||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need a link in the quickstart pointing to this doc.
@costrouc I can help get this wrapped up, it looks like we're fairly close to getting this merged. |
@costrouc this looks great, currently in the docs we have https://www.nebari.dev/docs/explanations/advanced-configuration#continuous-integration-and-continuous-deployment it would be cool if we could update that to include a reference to this page |
Co-authored-by: Kim Pevey <[email protected]>
Co-authored-by: Kim Pevey <[email protected]>
superseded by #473 |
Closes #281