I'm new to Helm, microservices and Kubernetes. For the past couple months I was working on a PoC and now I'm trying to setup a pipeline in Azure DevOps for deploying a chart that I'm currently upgrading manually.
Currently I have an umbrella chart for defining among other things, each microservice as a requirement (requirements.yaml):
dependencies:
- name: serviceA
version: 0.1.0
repository: "file://../serviceA/charts/serviceA"
- name: serviceB
version: 0.1.1
repository: "file://../serviceB/charts/serviceB"
For each microservice, I have a value.yaml where I define the image and the repo like this:
image:
repository: myacr.azurecr.io/serviceA
tag: 8ca05e4
pullPolicy: IfNotPresent
So far I was upgrading the deployment in this way:
- Build and push Docker Images to ACR
- Foreach microservice chart, bump the Chart version and update the Image Tag
- Update the microservice version in the Umbrella chart
- Finally to deploy the solution:
helm dep update
helm dep build
helm upgrade ....
Since I'm learning my way into Helm and Kubernetes, I might not have taken the best decisions.
However, this setup gives me what I currently need, a way to update only what has changed.
Now I'm trying to move this manual process to a pipeline in Azure DevOps.
I'm using a single repository for the services A & B.
So far what I was able to do in the pipeline is to build and push each service image to ACR (if something changed). I'm using the commit hash for tagging the images.
Finally, here are my questions or if someone would have some advise on how should I:
How can I bump each microservice chart version?
How can I update the image tag for each chart?
How can I bump the versions in the umbrella chart?
Any help or advise would be appreciated!
You can probably do a workaround in your pipeline to update the image tag and chart version using the YAML processor yq. Please go through https://github.com/mikefarah/yq
Ex:
yq w -i serviceA/Chart.yaml version <version>
yq w -i serviceA/values.yaml image.tag <image-tag-name>
yq w -i parentChart/Chart.yaml version <version>
However, the Chart version must follow the SemVer 2 standard.
Related
I want to create ArgoCD Application(app#1) that will contain an operator (for instance, Postgres operator) and I want to create another ArcoCD Application(app#2) but this time this application(app#2) should be the instance of the Postgres DB itself and be managed by its operator that is installed with app#1. Is it possible using Argocd source code to create this app#2 with CRD of Postgres DB(this CRD is likely part of helm chart of Postgres operator)?
I'm not entirely sure if I got your question right, however you can use the "apps of apps" pattern to have one ArgoCD application, install several other applications on your behalf. You can read the official docs here: https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/
We have a helm chart and we templatize it.
After this, we get n number of yml files. We deploy them one at a time using KubernetesClient.
Any idea how to deploy them all together?
Thanks,
Swaraj
Looking at the source code for the yarn builder for Google Cloud Build I was wondering why it is recommended to use the builder rather than specifying the entrypoint.
https://github.com/GoogleCloudPlatform/cloud-builders/tree/master/yarn
Basically
steps
- name: 'gcr.io/cloud-builders/yarn'
args:
- install
vs
steps:
- name: node:10
entrypoint: yarn
args:
- install
Is it because the cloud builder is registered with the Google Cloud Container Registry which is faster to read from within Google Cloud build?
Yes, you are corrected. Indeed, it's recommended because the read from the Container Registry will be faster to be done, using the builder.
As per the code indicates, you referencing directly the Container from yarn, which will make the access faster than using an entrypoint.
Let me know if the information helped you!
I have a single repository that hosts my lambda functions on github. I would like to be able to deploy the new versions whenever new logic is pushed to master.
I did a lot of reasearch and found a few different approaches, but nothing really clear. Would like to know what others feel would be the best way to go about this, and maybe some detail (if possible) into how that pipeline is setup.
Thanks
Welcome to StackOverflow. You can improve your question by reading this page.
You can setup a CI/CD pipeline using CircleCI with its GitHub integration (which is an online Service, so you don't need to maintain anything, like a Jenkins server, for example)
Upon every commit to your repository, a CircleCI build will be triggered. Once the build process is over, you can declare sls deploy, sam deploy, use Terraform or even create a script to upload the .zip file from your GitHub repo to an S3 Bucket and then, within your script, invoke the create-function command. There's an example how to deploy Serverless applications using CircleCI along with the Serverless Framework here
Other options include TravisCI, AWS Code Deploy or even maintain your own CI/CD Server. The same logic applies to all of these tools though: commit -> build -> deploy (using one of the tools you've chosen).
EDIT: After #Matt's answer, it clicked that the OP never mentioned the Serverless Framework (I, somehow, thought he was already using it, so I pointed the OP to tutorials using the Serverless Framework already). I then decided to update my answer with a few other options for serverless deployment
I know that this isn't exactly what you asked for but I use Serverless Framework (https://serverless.com) for deployment and I love it. I don't do my deployments when I push to my repo. Instead I push to my repo after I've deployed. I like this flow because a deployment can fail due to so many things and pushing to GitHub is much less likely to fail. I this way, I prevent pushing code that failed to deploy to my master branch.
I don't know if you're familiar with the framework but it is super simple. The website describes the simple steps to creating and deploy a function like this.
1 # Step 1. Install serverless globally
2 $ npm install serverless -g
3
4 # Step 2. Create a serverless function
5 $ serverless create --template hello-world
6
7 # Step 3. deploy to cloud provider
8 $ serverless deploy
9
10 # Your function is deployed!
11 $ http://xyz.amazonaws.com/hello-world
There are also a number of plugins you can use to integrate easily with custom domains on APIGateway, prune older versions of lambda functions that might be filling up your limits, etc...
Overall, I've found it to be the easiest way to manage and deploy my lambdas. Hope it helps!
Given that you're using AWS Lambda, you may want to consider CodePipeline to automate your release process. [SAM(https://docs.aws.amazon.com/lambda/latest/dg/serverless_app.html) may also be interesting.
I too had the same problem. I wanted to manage 12 lambdas with 1 git repository. I solved it by introducing travis-ci. travis-ci saved the time and really useful in many ways. We can check the logs whenever we want and you can share the logs to anyone by sharing the URL. The sample documentation of all steps can be found here. You can go through it. 👍
I have recently installed IBM Cloud Private 2.1 after trying out ICP 1.2 for a while. After the new install, I no longer see local-charts options such as Jenkins and Tomcat. I see the local-charts entry in the repository, but those charts don't seem to be loading. Thanks...
We are porting over the charts and will shortly make them available in our new online repo at https://github.com/IBM/charts.
While waiting for the IBM Charts, you can try the open source charts as well.
To be able to deploy jenkins, you can try to add repository as follow.
Name: stable
Url: https://kubernetes-charts.storage.googleapis.com
For Tomcat, try the incubator from bitnami
Name: bitnami-incubator
Url: https://charts.bitnami.com/incubator
Click sync after you add and you should be able to see the charts in the catalog.
Alternatively, you can download the charts and load it into the local charts with the IBM Cloud Private command line tool (bx pr load-helm-chart).