Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you may not be able to execute some actions.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Combine Helm charts or leave separate?

E
esther last edited by

I'm new to Helm and my first task was to recreate a simple pipeline. This pipeline is just:

PostgreSQL -> Spark, with ELK monitoring the instances.

Someone mentioned I may be able to combine all of these into a single Helm chart; such that when I run the Helm chart it spins up PostgreSQL, Spark, and ELK. Is there any advantage to this? Before I attempt to do this, is it a best practice or would it be better to keep each one separate?
Reply Quote 0
1 Reply Last reply
Marcee last edited by

Using https://kustomize.io/ you can combine multiple helm charts and make tweaks to them on the fly. https://jfrog.com/blog/power-up-helm-charts-using-kustomize-to-manage-kubernetes-deployments/ for doing this sort of thing.
Reply Quote 0
1 Reply Last reply

2
Posts

0
Views

Suggested Topics

C

Helm install or upgrade release failed on Kubernetes cluster: the server could not find the requested resource or UPGRADE FAILED: no deployed releases
Continuous Integration and Delivery (CI, CD) • docker kubernetes deployment continuous deployment helm • • charlenef

2

0
Votes

2
Posts

1
Views

Yes this happens frequently when debugging helm releases. The problem happens when a previously failed release is preventing you from updating it. If you run helm ls you should see a release in state FAILED. You might have deleted it in which case it might show up with helm ls -a. Such a release cannot be upgraded using the normal approach of having helm compare the new yaml to the old yaml to detect what objects to change as it is a failed release. As this normally happens when trying to get something new running I typically helm delete —purge the failed release. That is slightly drastic though so you may want to try to do the upgrade adding —force https://github.com/helm/helm/pull/2280
J

Is it possible to combine failure stage from groovy with try catch from pipeline?
Continuous Integration and Delivery (CI, CD) • jenkins pipeline groovy • • Jolied

2

0
Votes

2
Posts

1
Views

N

You may use and update a flag to false in the catch and then use that flag in the when directive of other stage(s) that you want to skip because of any failure in the given stage. Example: boolean flagStageOneSuccess = false pipeline { agent any stages { stage ('stage-1') { steps { try { // Do something that might fail flagStageOneSuccess = true } catch (Exception e) { // Handle the exception flagStageOneSuccess = false } } } stage ('stage-2') { when { equals expected: true, actual: flagStageOneSuccess } steps { // Do something in stage-2 } } } } It would also benefit you in viewing the status of your stage in Blue Ocean. If the stage is skipped, it shows as 'Not built'.
D

Proper way to showcase multi-container web app to customers
Continuous Integration and Delivery (CI, CD) • docker kubernetes provisioning • • Duquan

2

0
Votes

2
Posts

1
Views

A

You mention that you are demonstrating this for a customer. The first question you should ask yourself (or, more pertinently, the customer) is : what does this customer really want? Why have they come to you for this work? What is the pain they are currently feeling, what value are you providing to them. Then, compare and contrast - show them the delta that your solution brings to them. It may be for example that they want to maintain a legacy application, but upgrade the hardware or underlying components ? In that case, show them how you have contained them with no negative experience to their users. It may be that they need to scale the capacity for usage of their application - they want to be able to meet demand elastically. Show them how by deploying in a container setup, you can scale out. It may be that they need four nines reliability - show them that you can have an easier HA setup - knock out one of the instances and prove that the application still works. It may be that they want faster delivery with no little impact on quality. Show that your delivery pipeline works smoothly with some automated tests and QA, with delivery and deployment. TL;DR : Find out what your customer wants. Demonstrate the existing way of doing things. Compare it with the "new" way, and highlight the delta.
D

How can I find what options I can set with a `helm install` that the chart provides?
Continuous Integration and Delivery (CI, CD) • helm • • Duquan

2

0
Votes

2
Posts

0
Views

J

You can use show values to see what options the chart provides, helm show values mysql-operator/mysql-innodbcluster What you'll get is a YAML file, here is a part of the above YAML output, tls: useSelfSigned: false # caSecretName: # serverCertAndPKsecretName: # routerCertAndPKsecretName: You an set the option for useSelfSigned as tls.useSelfSigned like this: helm install mycluster mysql-operator/mysql-innodbcluster --set tls.useSelfSigned=true
No Docker container launch.
Software Programming • django docker docker compose sh • • Analeea

2

0
Votes

2
Posts

0
Views

Dockerfile in ENTRYPOINT is worth pointing out the whole way, not the relative.I mean, write like that.ENTRYPOINT ["/usr/src/app/entrypoint.sh"] This docker is working:FROM python:3.8-alpine # set work directory WORKDIR /usr/src/app set environment variables ENV PYTHONDONTWRITEBYTECODE 1 ENV PYTHONUNBUFFERED 1 RUN python -m pip install --upgrade pip install psycopg2 dependencies RUN apk update && apk add postgresql-dev gcc python3-dev musl-dev install dependencies RUN apk update && apk add g++ gcc libxml2 libxslt-dev COPY ./req.txt . RUN pip install -r req.txt COPY ./entrypoint.sh /usr/src/app/entrypoint.sh copy project COPY . . RUN chmod +x /usr/src/app/entrypoint.sh ENTRYPOINT ["/usr/src/app/entrypoint.sh"]
S

How do you change the docker-form design?
Software Programming • linux ubuntu docker • • Saumya

2

0
Votes

2
Posts

0
Views

J

Do a new Dockerfile and indicate the previous image in the directive. FROM♪ So you add a new layer and create a new image with your changes.
Route webhook to all replicas
Continuous Integration and Delivery (CI, CD) • kubernetes • • Bogopo

2

0
Votes

2
Posts

1
Views

Y

This is something you'd have to build. Kubernetes doesn't natively offer this as a pattern. There are a few approached you can take, but a common on is to use a queue that has this functionality. I'd suggest starting with Nats because it's a CNCF project that is easy to run natively in Kubernetes. When one of your replicas receives the request, it can post a message to the queue that can deliver the message to every subscriber.
S

TerraForm separate stages
Continuous Integration and Delivery (CI, CD) • terraform terraform module terraform workspace • • Saumya

2

0
Votes

2
Posts

0
Views

J

I don't think there are any best practices because it would depend on both your company structure as well as how your developers manage their code in SCM (gitflow, trunk, etc). Lets start with the statements that seem to be in contradiction. I think quoted like that they do seem to tell a different story. But lets look at the start of the paragraph where the first quote came from. When Terraform is used to manage larger systems, teams should use multiple separate Terraform configurations that correspond with suitable architectural boundaries within the system so that different components can be managed separately and, if appropriate, by distinct teams. So it's saying that when you have multiple teams using the same terraform directory (aka configuration) then... Workspaces alone are not a suitable tool for system decomposition, because each subsystem should have its own separate configuration and backend, and will thus have its own distinct set of workspaces. Which makes sense. Each team will need different things from their workspace and since all the teams will be sharing workspaces then it kinda falls apart. So in conclusion, different directories and workspaces can be used to separate environments in Terraform but they have certain limitations. In the tutorial you linked, I think it's explained even better: To separate environments with potential configuration differences, use a directory structure. Use workspaces for environments that do not greatly deviate from one another, to avoid duplicating your configurations. The second part of your question about recommendations can get somewhat complicated depending on what level of CICD and automation your company currently has. If your infra is small and the number of changes every month is pretty minimal then it's probably fine to just checkout the code, make the change and deploy it locally. But if you are a large organization with 100's of changes a week, then you are probably going to want to automate the deployments. A common way of doing that is to trigger CICD on new PR's or changes to certain branches. From there you can have your CICD engine change workspaces based on the branch name. Or more commonly for older companies who used Terraform before workspaces existed, you can just set the state path to something like ${env}/tf.state because that really has the same effect as just using workspaces. I'm a Terraform and https://github.com/gruntwork-io/terratest/releases/tag/v0.28.5 contribtutor. I'm also the author of https://github.com/DontShaveTheYak/cf2tf and the https://github.com/DontShaveTheYak/terraform-module-template .
D

Examination of Docker packages
Software Programming • docker • • derk

2

0
Votes

2
Posts

0
Views

C

Initiate containers online and use the full-time teams of the package manager(apt/dnf/apk etc, whichever is the basis for the.)
E

Is there a way to push tarred repository to dockerhub without loading on local
Continuous Integration and Delivery (CI, CD) • docker docker registry dockerhub • • esther

2

0
Votes

2
Posts

1
Views

Actually this is not possible as docker push command will look for a local image or a repository. You will have to load your image first from tar file, the push it to your registry. docker load --input repo.tar docker image tag myrepo registry-host:5000/myrepo/myrepo:v1 docker image push registry-host:5000/myrepo/myrepo:v1
D

Separation of CI and CD processes
Continuous Integration and Delivery (CI, CD) • process deployment methodology continuous delivery monorepo • • Duquan

2

0
Votes

2
Posts

1
Views

T

You're basically describing GitOps. Here's how I've followed that for a containerized microservices build and deploy pipeline: Each service repo includes it's own Dockerfile, Kubernetes manifests, and anything else needed to locally build and test the project. The base image for the Dockerfile will likely be managed from another repo but built and hosted by the organization. CI steps are mostly externalized to a set of common libraries or templates. So if there's a Jenkinsfile or equivalent, it sets a few variables and calls the common template to build and generate the artifacts. Artifacts include a docker image, pushed to a registry, and also the deployment manifest (compose file, Kubernetes manifest, Helm templates), along with any other variables for those manifests. These deployment manifests/variables are pushed to a separate deployment repository that includes all of the microservices' manifest. There is only one deployment repo for all of the microservices in a single application stack, so this commit becomes a fan-in step. The push to this repository is scripted/automated during the CI of the microservice repo when a pull request is approved by enough trusted people to a protected branch. This provides the needed security checks. The deployment repo commits triggers it's own pipelines that are effectively CD and following something close to a GitOps design. This could also be a GitOps tool monitoring the repo and applying the changes, but presently I've been sticking with a single CI tool that does both, simplifying the workflow and allowing some scripting to run on the deploy. That scripting for me loads the variables that were committed, applies additional variables (e.g. which environment is this being deployed to), renders the templates (currently a Helm umbrella chart), and deploys. Deploys to other environments becomes a pull request between branches of the deploy repository. It could also be separate repositories to enforce security controls. Importantly, rendering the manifest should point to an immutable image tag or sha hash to ensure what was pushed to dev and tested there is the same as what's pushed to production. I include these image tags in a values file that is committed to the deploy repo. One big advantage of this, multiple microservices that interact with each other are tested together and get deployed together as a unit, all services are fanning into a single deploy repo that contains their deployment manifests and what image tag to use. There's never the situation where service A gets a new feature, but it's buggy, service B gets built depending on that new feature, and service B gets released to production before service A (a common issue when each service is built and deployed in isolated pipelines). If A is blocking the deployment of the stack, then a pull request can be submitted to the deploy repo reverting the service A commit. Then if service B passes tests against an older service A, service B gets deployed to production.
docker volumes on cifs share cause permission disaster
Continuous Integration and Delivery (CI, CD) • docker containers • • Laycee

2

0
Votes

2
Posts

1
Views

D

The problem can be solved by using mount options that force the application of the correct user and group eventhough these attributes can't really be set on the target system its sufficient to get around the docker related problem. Also a reasonable set of privileges needs to be defined that is used for new files and folders. mount -t cifs -o username=user,password=pass, \ # provide creds uid=www-data,forceuid,gid=root,forcegid, \ # force gid and uid file_mode=744,dir_mode=744 //host/share /local/mountpoint # set permissions for new files and directories
M

Elasticsearch on Docker - file permission issues
Continuous Integration and Delivery (CI, CD) • windows docker elasticsearch • • meriah

2

0
Votes

2
Posts

1
Views

I have discovered the issue, the path to the role_mapping.yml file was incorrect in elaticsearch.yml. I had to use the full path /usr/share/elasticsearch/config/role_mapping.yml
Use one Helm chart for ALL microservices?
Continuous Integration and Delivery (CI, CD) • kubernetes helm kubernetes helm • • Laycee

2

0
Votes

2
Posts

1
Views

G

Generally, a Helm chart would cover all your microservices - ideally, you should be able to deploy whole application in one chart. It may get a little messy if you include external 3rd party dependencies, where you would need to handle dependent charts, but I assume this is out of scope of your question. More so, if your microservices are very similar you could write for loops, such as: {{- range $index, $service := .Values.myservices}} apiVersion: apps/v1 kind: Deployment metadata: name: myapp-{{ $service.name }} # --- etc --- {{- end }} Now, where to put your chart - in most cases a preferred way is to have a separate repo for all Ops CD files, including Helm chart - so this is where Helm chart would live. This is not to be mixed with CI files, such as Dockerfile - those should live alongside microservice repositories themselves.
C

Using docker with users leaves files belonging to the subuid/subgid
Continuous Integration and Delivery (CI, CD) • permissions docker user namespaces • • Cleofas

2

0
Votes

2
Posts

1
Views

N

docker run -ti --rm \ -v $PWD:/workdir \ -v $HOME/.ssh:/root/.ssh \ --user $(id -u):$(id -g) \ dockerizedxyz "$@" As long as you're not doing anything funny with the entrypoint in the container, this will leave files owned as the user that invoked Docker.

Combine Helm charts or leave separate?

Suggested Topics

Helm install or upgrade release failed on Kubernetes cluster: the server could not find the requested resource or UPGRADE FAILED: no deployed releases Continuous Integration and Delivery (CI, CD) • docker kubernetes deployment continuous deployment helm • • charlenef

Is it possible to combine failure stage from groovy with try catch from pipeline? Continuous Integration and Delivery (CI, CD) • jenkins pipeline groovy • • Jolied

Proper way to showcase multi-container web app to customers Continuous Integration and Delivery (CI, CD) • docker kubernetes provisioning • • Duquan

How can I find what options I can set with a `helm install` that the chart provides? Continuous Integration and Delivery (CI, CD) • helm • • Duquan

No Docker container launch. Software Programming • django docker docker compose sh • • Analeea

How do you change the docker-form design? Software Programming • linux ubuntu docker • • Saumya

Route webhook to all replicas Continuous Integration and Delivery (CI, CD) • kubernetes • • Bogopo

TerraForm separate stages Continuous Integration and Delivery (CI, CD) • terraform terraform module terraform workspace • • Saumya

Examination of Docker packages Software Programming • docker • • derk

Is there a way to push tarred repository to dockerhub without loading on local Continuous Integration and Delivery (CI, CD) • docker docker registry dockerhub • • esther

Separation of CI and CD processes Continuous Integration and Delivery (CI, CD) • process deployment methodology continuous delivery monorepo • • Duquan

docker volumes on cifs share cause permission disaster Continuous Integration and Delivery (CI, CD) • docker containers • • Laycee

Elasticsearch on Docker - file permission issues Continuous Integration and Delivery (CI, CD) • windows docker elasticsearch • • meriah

Use one Helm chart for ALL microservices? Continuous Integration and Delivery (CI, CD) • kubernetes helm kubernetes helm • • Laycee

Using docker with users leaves files belonging to the subuid/subgid Continuous Integration and Delivery (CI, CD) • permissions docker user namespaces • • Cleofas

Helm install or upgrade release failed on Kubernetes cluster: the server could not find the requested resource or UPGRADE FAILED: no deployed releases
Continuous Integration and Delivery (CI, CD) • docker kubernetes deployment continuous deployment helm • • charlenef

Is it possible to combine failure stage from groovy with try catch from pipeline?
Continuous Integration and Delivery (CI, CD) • jenkins pipeline groovy • • Jolied

Proper way to showcase multi-container web app to customers
Continuous Integration and Delivery (CI, CD) • docker kubernetes provisioning • • Duquan

How can I find what options I can set with a `helm install` that the chart provides?
Continuous Integration and Delivery (CI, CD) • helm • • Duquan

No Docker container launch.
Software Programming • django docker docker compose sh • • Analeea

How do you change the docker-form design?
Software Programming • linux ubuntu docker • • Saumya

Route webhook to all replicas
Continuous Integration and Delivery (CI, CD) • kubernetes • • Bogopo

TerraForm separate stages
Continuous Integration and Delivery (CI, CD) • terraform terraform module terraform workspace • • Saumya

Examination of Docker packages
Software Programming • docker • • derk

Is there a way to push tarred repository to dockerhub without loading on local
Continuous Integration and Delivery (CI, CD) • docker docker registry dockerhub • • esther

Separation of CI and CD processes
Continuous Integration and Delivery (CI, CD) • process deployment methodology continuous delivery monorepo • • Duquan

docker volumes on cifs share cause permission disaster
Continuous Integration and Delivery (CI, CD) • docker containers • • Laycee

Elasticsearch on Docker - file permission issues
Continuous Integration and Delivery (CI, CD) • windows docker elasticsearch • • meriah

Use one Helm chart for ALL microservices?
Continuous Integration and Delivery (CI, CD) • kubernetes helm kubernetes helm • • Laycee

Using docker with users leaves files belonging to the subuid/subgid
Continuous Integration and Delivery (CI, CD) • permissions docker user namespaces • • Cleofas