Deploying Youtap applications with Helm

Prerequisite:

Tools:

https://youtap.atlassian.net/l/cp/1mxkhsvJ

Clone Repo

git clone http://x.x.x.x/infrastructure/helm-application-deployment.git

Deployment:

1. Create branch for change of version

Checkout branch based on which environment going to be upgraded. For example for youtap test environment, checkout feature/youtap-test. Then optionally create your own branch for updating the helm chart, if you want to keep it separate until it’s ready. Remember to merge your change.

2. Changing the chart

What is helm chart and what to change: https://youtap.atlassian.net/l/cp/YgLsKMBG

• Editing details and then wanting to apply them requires a different command

  • It’s important to check whether the new deployment requires configuration changes, such as URLs or other configurable values in the application.properties file for the service.

  • Make sure to include any liquibase updates that are required by the new service versions

3. log into environment with AWS

aws sso login --profile <PROFILE>

4. Changing between accounts

See all account/eks options

kubectl config get-contexts

Change context

kubectl config use-context <CONTEXT>

Check context

helm list

5. deployment

helm upgrade <name> .

This will make the changes and increment the revision number of the active chart

Release "test-helm" has been upgraded. Happy Helming!
NAME: test-helm
LAST DEPLOYED: Mon Jun 20 09:42:32 2022
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None

On Versioning

There are 2 version numbers to keep track of on the helm chart.

• The first is to track changes to the chart itself (changing templates,infrastructure details, etc)

• The second is to track changes to the applications themselves. This is the maintenance release version for staging and production services. For development and testing this will likely be much less formal.

Installing applications

• run helm command from inside the repo root folder

helm install <name> .

e.g.

helm install youtap-test .

• or from parent folder

helm install youtap-test helm-application-deployment

Deploying/Releasing to Higher Environments

Including Configuration in YouTap Test Deployments

Configuration changes are usually fairly simple, but can have a critical impact on behavior if overlooked. When there are no other Helm-based deployments to look at - such as in the case of test environment updates - you will have to go through each ticket/commit individually to check for changes to the dev-deployment.yml file. If the file was unchanged you can skip that ticket and check the next commit/service, but if the file was changed make sure to include the appropriate value(s) in the right config map for the deployment you’re upgrading.

Post-Test Environments (SIT, Staging, and Production)

While deployments to dev and test environments usually involves a fairly large group of individually quite simple changes brought together from several projects, promoting those changes to environments such as SIT or staging often requires migrating the end result of several of those groups of changes without including environment-specific configuration such as URLs and certificates.

Instead of combing through lists of commits and updating the version numbers for the same services over and over, another possible method is to compare the branch as a whole. This allows the user to go over the config file once, as long as they know what to leave and what to take. It does increase the risk of misconfiguring the environment, but being careful with the modifications and monitoring the services afterwards reduces the potential damage.

Method:

Make sure you fetch any changes to make sure your git is up to date.

First check how many commits are eligible to be included in the upgrade. If it’s only one (or even two) you should use the contents of that commit instead of this method. Assuming there are several commits to include:

1. Check out the target environment branch in the Helm deployment project

2. Right-click the source branch and click “compare with local” or the equivalent in your Git interface. This should bring up a list of files that are different between the two branches. Generally we are only interested in the “values.yaml” file, although the other files have important changes from time to time.

3. Open the comparison for each of the files we want to bring changes from one at a time. For each file go through each difference and copy it into your local version unless it falls under one of the following categories (NB if the value is new it may need to be included with another value, but the one from the source environment shouldn’t be used):

   1. Certificate configuration

   2. Environment-specific URLs/hostnames/resource names (anything with staging, test, dev, etc. in the path, or 3rd-party services that are only used for certain environments)

   3. Resource requests/limits

   4. Replicas

   5. Auth configuration

   6. Secrets

   7. Logging level differences

   8. Other changes (including removing pieces of configuration) may be inappropriate to include. If you’re not sure, go back and find where the modification came from in the git history. If it’s not specifically one of the commits that you’re trying to migrate it’s almost certainly not supposed to be included in the upgrade.

4. Once you have all of the upgrade components together:

   1. Commit and push your changes before running the upgrade. This makes sure that your changes are saved and nobody else is going to run another upgrade that interferes with your work.

   2. Follow the instructions above for deploying applications.