carvel-dev / carvel

Carvel provides a set of reliable, single-purpose, composable tools that aid in your application building, configuration, and deployment to Kubernetes. This repo contains information regarding the Carvel open-source community.
https://carvel.dev/
Apache License 2.0
376 stars 117 forks source link

Are you using Carvel? #213

Open microwavables opened 3 years ago

microwavables commented 3 years ago

Are you using Carvel?

If you are using any of the Carvel tools, first we would like to Thank You. Our goal is to grow the community, improve Carvel and help each other.

The purpose of this issue

We are always interested in finding out who is using Carvel, what attracted you to using the tool suite, how we can listen to your needs, and, if you are interested, help promote your organization.

What we would like from you

Submit a comment in this issue to include the following information, which would then also get included into the ADOPTERS.md file in this repo for others to see:

If you have any questions please Email Us.

Organization/Company: 
Website: 
Country: 
Contact: 
Usage scenario: 
Status: Production // Testing
vrabbi commented 3 years ago

TeraSky Company: TeraSky Website: https://terasky.com Country: Israel Contact: @vrabbi (github and k8s slack) @vrabbi_il (twitter) Usage: TeraSky is an Advanced Technology Solutions Provider. We utilize the carvel suite in order to streamline k8s configuration and deployment by many of our customers. We also utilize ytt to manage additional yaml based systems such as vRealize Automation and CloudFoundry. Status: Production

vrabbi commented 3 years ago

I used a png file as it complains about not supporting svg format uploads

microwavables commented 3 years ago

I used a png file as it complains about not supporting svg format uploads

@vrabbi ah, good to know! I updated the text to "PNG" thank you!!

adriens commented 3 years ago

✋Intro

Hi, I'm Adrien Sales from OPT-NC New Caledonia

image

✅Questions

OPT-NC

ChristianCiach commented 3 years ago

Hi! I am not quite ready to disclose the organization I am working for and make things official. I probably need clearance from upper management for that.

But let me just take this opportunity to say thank you for your work! We've just introduced kbld and kapp into our deployment pipelines, and these are a big help!

Some background: We recently moved from "Docker Swarm" to Kubernetes (self hosted k3s). We are templating our yaml-files (previously docker-compose-yaml, now kubernetes-yaml) using Ansible/Jinja, because our teams are used to Ansible and we didn't have time to switch to another templating engine, so Helm was no option for us.

So, at first our pipeline looked like this:

  1. Ansible+Jinja to generate a set of docker-compose files for Docker swarm, one file for each application (called "stack" in Docker-Swarm)
  2. Deploy using docker stack deploy -f docker-compose.yaml [stack-name]

You can probably see where I am going with this: Docker-Swarm has the concept of "stacks" that roughly translate to "apps" when using kapp. So, when updating a stack later with a new docker-compose.yaml-file that contains fewer services than before, Docker-Swarm was smart enough to remove the now-missing service from the stack.

Also: When deploying using docker stack deploy, docker first converts all image-tags into image-digests. This ensures that all nodes use the exactly same image, even when deploying latest tags.

After switching to Kubernetes, our pipeline initially looked like this:

  1. Use Ansible+Jinja to generate a set of kubernetes manifests (Deployment, Service, Ingress, ....)
  2. Use Kustomize to merge all files of one application into a single kubernetes.yaml (which is our replacement for the docker-compose.yaml files from before) while also using its configMapGenerator and secretGenerator to convert raw files into ConfigMaps and Secrets.
  3. Deploy using kubectl apply -f kubernetes.yaml for each application.

This works nicely, but we quickly encountered two issues:

As I already said, we absolutely have to use Ansible (for variables management) and Jinja (for templating), because migrating away from these would be a huge project by itself. This means we can't use Helm. And let's be real: Most people seem to hate Helm with strong passion.

This was when I discovered the carvel tools:

Our pipeline now looks like this:

  1. Use Ansible+Jinja to generate a set of kubernetes manifests (Deployment, Service, Ingress, ....)
  2. Use Kustomize to merge all files of one application into a single kubernetes.yaml (and generate ConfigMaps and stuff).
  3. Pipe the kubernetes.yaml of each application through kbld to convert image tags to digests.
  4. Deploy using kapp deploy -a [app-name] -f kubernetes.yaml for each application.

This works really well!

Seriously, I think the carvel tools deserve a lot more love from the community. When searching sites like hacker-news and reddit for tools like "kapp" you barely find any mentions of them. I am really curious about why this is the case, because I think these tools really fill a gap, especially if you don't want to use Helm.

microwavables commented 3 years ago

@ChristianCiach thank you so much for these details and community love! Let us know if/when you can disclose the org you work for. We'd love to know what organizations are using Carvel :) I'll make sure the rest of the team sees your comment, as well. We'd also love to have you join one of our community meetings to virtually meet you over Zoom. Details here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw

devthejo commented 2 years ago

Organization: Fabrique Numérique des Ministères Sociaux Website: https://www.fabrique.social.gouv.fr/ Country: France Usage: We are using kapp CLI as deployer for our CI/CD tooling that we are developing and implementing actively: Kontinuous The project started as a wrapper around Helm and Kapp, then evolved to offer more abstraction and a rich plugins system. Doc will be updated soon to reflect our current state of art. Many thanks for great tooling you provide ! Dependencies tree management using change-group and change-rules are greatly valuable and offer much flexibility for our use cases.

gberche-orange commented 1 year ago

Thanks for the great work and welcoming community. Carvel has been solving problems that I was facing in a pure gitops workflow using Fluxcd2.

corneil commented 1 year ago

Thank you for the great work.

Havnevej commented 1 year ago

We are in the Platform team at nemlig.com, developing an in-house kubernetes platform, which is deployed, managed and configured using a plethora of open-source tools like: kcli, helm and many many more.

We have developed the platform from scratch, stitching together many open-source tools. But a few of the most important tools in our toolbox is yq, jq and of course the glue that binds all of the tools together ytt.

Ytt is often the last step before helm install in a tool we have created called the component-handler which, as the name eludes to, handles components (e.g., helm releases in our clusters) in a generic but also hugely extendable way. Without ytt, this had been hell for us to develop like we wanted it, so we are very grateful for this awesome tool and are planning to contribute back when time allows. Awesome work you guys!

microwavables commented 1 year ago

@Havnevej thank you so much for your contribution to this issue!