Open microwavables opened 3 years ago
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
I used a png file as it complains about not supporting svg format uploads
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!!
Hi, I'm Adrien Sales from OPT-NC New Caledonia
vendir
to sync repos to build docker images, ytt
to instanciate templates and are currently working on packaging services as applications with kapp
. We are prototyping on a onPrem Tanzu instance. We are using Github.com and GH Actions to automate the whole thing and are evaluating Harbor vs. Artifactory vs. Github Container Registry to store/release our images, also for public ones DockerHubHi! 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:
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:
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.kubectl apply -f kubernetes.yaml
for each application.This works nicely, but we quickly encountered two issues:
kubectl apply
doesn't convert latest
-tags to digests. This leads to unexpected image-updates when kubernetes relocates a container from one node to another. Also, kubectl apply
doesn't create new pods if the contents of the manifests have not changed, even though the developer expects the recreation of pods if the latest
image has been updated in the meantime.kubernetes.yaml
(which, again, is a concatenation of all kubernetes resources that together describe an application) contains fewer resources than before (like a removed Ingress), kubectl apply
won't delete the removed resource from the cluster. (Yes, I know about --prune
, but let's not speak about that....).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:
kubernetes.yaml
(and generate ConfigMaps and stuff).kubernetes.yaml
of each application through kbld to convert image tags to digests.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.
@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
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.
Thanks for the great work and welcoming community. Carvel has been solving problems that I was facing in a pure gitops workflow using Fluxcd2.
Thank you for the great work.
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!
@Havnevej thank you so much for your contribution to this issue!
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.