-
Notifications
You must be signed in to change notification settings - Fork 171
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
Containerized Full RP Dev Automation #3764
base: master
Are you sure you want to change the base?
Conversation
b14a484
to
ac0370b
Compare
/azp run ci, e2e |
Azure Pipelines successfully started running 2 pipeline(s). |
50ec943
to
942e53d
Compare
I added some fixes due to moving to |
/azp run ci,e2e |
Azure Pipelines successfully started running 2 pipeline(s). |
942e53d
to
9607fb5
Compare
It respects .dockerignore, thus .bingo directory should be included. When untar an archive of secrets we should use --no-same-owner to not modify the ownership. No need to check if dev-config.yaml exists when it is already ignored. Furthremore the new build us with no cache, when log in to ACR you will use -ojson flag, and we compare repo tag vs each existing tag
575d05d
to
9a78b8f
Compare
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 reviewed several files but I need to come back and review more with fresh eyes.
9a78b8f
to
b9decba
Compare
/azp run ci,e2e |
Azure Pipelines successfully started running 2 pipeline(s). |
…y fix Using dockerignore will not pass all the files from the repo, resulting with dirty git status and running the deploy target with dirty suffix. regardless of the git repo state. Allow user import access to the 3 KeyVaults we store the certs
b9decba
to
69c86c8
Compare
/azp run ci,e2e |
Azure Pipelines successfully started running 2 pipeline(s). |
There is an issue with importing certs to 3 keyvaults when running the Full RP automation:
ATM the automation fails on the first try for missing the DipAvailability metric, and on the second try with
|
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 still need to review more closely the rest of changes. I just happened to see the change in deploy code is a blocker for merging, imo.
cmd/aro/deploy.go
Outdated
if err != nil { | ||
return err | ||
} | ||
|
||
// Must be last step so we can be sure there are no RPs at older versions | ||
// still serving | ||
return deployer.SaveVersion(ctx) |
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.
After the split of the original function, SaveVersion
has ended in two places, here and in the new deploy
function, but this should not be called before we have deployed the RP and Gateway. This will cause problems in Production, because the new version can be stored even if the actual deploy fails while we still keep the older deploy.
Also, this split is being reflected only in the Makefile, but this refactoring will have implications also in the Production pipelines because we will be only calling aro deploy
there. Hence, this invalidates the deployment test we did in INT.
We should not be save version before we have deployed the RP and Gateway. This will cause problems in Production, because the new version can be stored even if the actual deploy fails while we still keep the older deploy.
/azp run ci,e2e |
Azure Pipelines successfully started running 2 pipeline(s). |
/azp run e2e |
Azure Pipelines successfully started running 1 pipeline(s). |
Please rebase pull request. |
The PR automates the full RP dev int-like procedure using dockerfile and Makefile.
Which issue this PR addresses:
Fixes ARO-9327
Procedure Steps and Timing:
On average the full automation takes 65 minutes in eastus and below are the procedure steps and timing (following the design):
What are these bash scripts?
rp_dev_helper.sh
bash script has functions that any SRE could use regardless of the Full RP automation for checking and using Azure resources.full_rp_funcs.sh
has functions that correspond to the designed steps of Full RP creation and are triggered withfull_rp_deploy.sh
inside your local container.What this PR does / why we need it:
The PR adds the capability of quickly and easily provisioning INT-like development environments without manual steps using a local containerized process.
How to run the ARO RP automation?
AZURE_PREFIX=aaa RP_LOCATION=eastus SKIP_DEPLOYMENTS=true make full-rp-dev
Comments:
${HOME}/.azure
.You can run
az account show --query state -o tsv
to check if your login to Azure CLI is successful. Look forEnabled
in the output.eastus
).true
) when you prefer to deploy Azure resources regardless of their existence.RP_FULL_DEV_IMAGE=YOUR_REPO_AND_TAG
) in case you want to push the container to your registry.AZURE_PREFIX=aaa clean_rp_dev_env eastus
orAZURE_PREFIX=aaa RP_LOCATION=eastus make full-rp-dev-clenup
(based on the above creation command).Which changes does it include?
usage_rp_funcs
andusage_rp_dev
to get functions' usage help.deploy
target into three targets:pre-deploy-full
andpre-deploy-no-aks
anddeploy
. It is needed due to rpServiceKeyvaultDynamic deployment which depends on aro-aks-cluster-001 that hasn't been set up ATM.Workaround for azsec-monitor problemDon't wait on Hive instllation- SImilar to Refactor Hive Directory #3765SKIP_DEPLOYMENTS=true
.### How to review?1. Checkout a new branch (e.g.,git checkout -b NEW_BRANCH
)2. Add changes, updateARO_RP_BRANCH
var to ARO_RP_BRANCH, and commit them ('git add .' and then 'git commit -m "MESSAGE"')3. Push the changes (e.g.,git push origin NEW_BRANCH
)Test plan for issue:
Run
AZURE_PREFIX=aaa RP_LOCATION=eastus SKIP_DEPLOYMENTS=true make full-rp-dev
to test if it fully deploys your ARO RP deployment.Limitation/Known-issues:
Is there any documentation that needs to be updated for this PR?
Yes at https://github.com/Azure/ARO-RP/blob/master/docs/deploy-full-rp-service-in-dev.md#deploying-an-int-like-development-rp
How do you know this will function as expected in production?
Many tests, and it is not planned to be used in production. Merely for SREs to have a fully running RP automated.