Het lijken soms wel twee verschillende werelden, dat ontwikkeling en beheer! Aan overbrugging wordt veel gedaan, maar soms vallen er toch wat gaten. Misschien komt dat wel omdat de tool-ecosphere van moderne softwareontwikkeling zo enorm snel groeit.
Een voorbeeld: de DevOps toolchain lijkt inmiddels vrij goed uitgekristalliseerd. In de meest rudimentaire vorm biedt het de mogelijkheid voor opslag van broncode (en artefacten), geautomatiseerd integreren en builden van broncode en geautomatiseerd testen en kwaliteitscontrole op het resultaat.
Maar hoe krijg je die gecompileerde code, applicatie, binary of container nu op Kubernetes? Het meest eenvoudig is dit te doen met behulp van commandline tool kubectl en het commando kubectl run. Een verstandige manier om (enterprise) applicaties te beheren is dat echter niet: met kubectl wordt bijvoorbeeld geen configuratie opgeslagen. Voor een enkele applicatie op een enkele omgeving voldoet de “kale” kubectl prima, maar voor iets meer schaalgrootte is het nodig Kubernetes te configureren, aan de hand van configuratiebestanden, templates en scriptingtaal yaml.
Een van de voordelen van een platform als OpenShift is dat het die zorg overneemt, bijvoorbeeld via een combinatie van Source-to-Image (https://github.com/openshift/source-to-image) en de ingebouwde tools van het platform voor transport van het image. Maar het kan ook anders.
In dit artikel een aantal tools die helpen om van bron naar Kubernetes te komen. Hiervan zijn Helm en KSonnet wat uitvoeriger beschreven, misschien omdat ze er net iets meer bovenuit steken dan de overige tools. Het gemeenschappelijke kenmerk van de tools is dat ze Kubernetes-objecten en applicaties beschrijven als code. Ze zijn allen in staat de lifecycle (installeren, upgraden, terugrollen) van applicaties te beheren.
Microsoft Helm (https://helm.sh/)
Helm is een van de verschillende Cloud-tools die in 2015 zijn gemaakt door Deis, nu onderdeel van Microsoft. De tool is open source en wordt beheerd door de Kubernetes community (https://github.com/kubernetes/helm). Het tool bestaat uit twee delen: een client (Helm) en een server (Tiller). Helm gebruikt als inpakformaat charts, een verzameling van configuratiebestanden geschreven in de scriptingtaal yaml. Tiller draait binnen het Kubernetes cluster en beheert deze charts. De documentatie (https://github.com/kubernetes/helm/blob/master/docs/charts.md) geeft een prima overzicht van hoe charts precies werken. Schrijven van charts is echter niet eenvoudig.
Helm heeft een publieke repository, waarin een grote verzameling van voorgedefinieerde charts is terug te vinden (https://hub.kubeapps.com/). Er is een handmatig reviewproces waardoor niet elke charts zomaar in de repository terecht kan komen. Het is ook mogelijk een private repository in te richten en te gebruiken.
Heptio KSonnet (https://ksonnet.io/)
Heptio is opgericht door Craig McLuckie en Joe Beda, die aan de wieg stonden van Kubernetes en Google Compute Engine. Met KSonnet is het mogelijk om applicatieconfiguratie voor Kubernetes te schrijven met behulp van een scriptingtaal die Jsonnet (https://jsonnet.org/) heet en – zoals de naam suggereert – json-documenten genereert. JSonnet is gebaseerd op verschillende standaarden van configuratiebestanden die binnen Google in gebruik zijn.
De filosofie van KSonnet is om op een of meerdere environments een application te deployen die uit verschillende components bestaat, die op hun beurt uit prototypes (en bijbehorende parameters) bestaan.
Een interessante richting die de ontwikkelaars van de tool voor zich zien, is om Helm charts mee te schrijven (zie bijvoorbeeld https://medium.com/@jbeda/great-questions-2f377959d9e0) . Ze zijn duidelijk op zoek naar standaardisatie en samenwerking.
Met een recent initiatief, onder andere gedreven vanuit Heptio, wordt geprobeerd meer onderlinge samenwerking te krijgen tussen de verschillende tools voor Kubernetes applicatiebeheer, bijvoorbeeld door te komen tot gemeenschappelijke standaarden en afspraken. (https://github.com/kubernetes/community/tree/master/wg-app-def).
Andere tools
Er zijn meer tools dan de twee die hierboven beschreven zijn.
Kapitan (https://github.com/deepmind/kapitan)
Een alternatief voor Helm (https://github.com/deepmind/kapitan), met name in het leven geroepen door de ontevredenheid van de auteur met de afhankelijkheid die Helm met Tiller heeft en de onhandigheid van het delen van waarden tussen Helm charts.
Kubecfg (https://bitnami.com/kubernetes)
Tool van Bitnami dat net als Ksonnet gebruik maakt van scriptingtaal Jsonnet. Volgens de makers van Ksonnet is het “less opiniated”. Niet te verwarren met de voorloper van het Kubernetes commandline tool kubectl.
Appscode Kubepack (https://kubepack.com/)
Appscode heeft een aantal tools beschikbaar die werken met Helm vereenvoudigen, zoals Chartify (https://github.com/appscode/chartify) om charts mee te genereren. Uit onvrede over de complexiteit van Helm maakten ze Kubepack, een eenvoudig deploytool. Kubepack gaat uit van Git als bron – met de configuratiebestanden toegevoegd is het mogelijk met commandline tool pack een deploy richting Kubernetes te doen.
Metaparticle (https://metaparticle.io/)
Met behulp van Metaparticle is het mogelijk om code te packagen als containers. Op dit moment is er ondersteuning voor java, .NET, javascript, go, python en ruby. Het voordeel hiervan is dat packaging (en deploy) mogelijk is vanuit een bestaande ontwikkelomgeving. Metaparticle genereert Dockerfiles en is daarmee relatief portabel, maar niet een platform zoals enkele andere hierboven genoemde tools.
Google Skaffold (https://github.com/GoogleContainerTools/skaffold)
Een tool dat in de achtergrond draait en vanaf de lokale ontwikkelomgeving iedere directory die is voorzien van een Dockerfile automatisch naar een Kubernetes cluster kan pushen (en bestaande omgevingen kan voorzien van geupdate versies van de code).
Weaveworks Flux (https://www.weave.works/oss/flux/)
Met Flux is het mogelijk om container images naar een productieomgeving te brengen. Uitgangspunt is dat de volledige containeromgeving ondergebracht is in een regime van version control, aangestuurd door Flux.
Gitkube (https://gitkube.sh/)
Tool van Hasura (met een interessante achtergrond, zie https://yourstory.com/2016/10/hasura-tech30/) voor het builden en deployen van docker images, dat gebruik maakt van de standaard git tooling (git push). Het voordeel van Gitkube is dat het gebruik maakt van de bekende tooling rondom Kubernetes en dus geen (andere) dependencies heeft.
Datawire Forge (https://forge.sh/)
Forge werkt net als Gitkube vanuit een standaard git repository, door de ontwikkelaars omschreven als een Kubernetes-native Docker compose. De verdere functionaliteit lijkt op Google Skaffold.
Microsoft Draft (https://draft.sh/)
Het tool Draft heeft een sterke relatie met Helm: eigenlijk is Draft bedoeld voor ontwikkelen en Helm voor deployen. Voor ontwikkelaars is het een manier om code snel naar een volgende omgeving te krijgen, maar het is niet bedoeld voor gebruik in productie.
Gerelateerde tools
Hieronder enkele tools die niet helemaal passen in het onderwerp van dit artikel, van Bron naar Omgeving – maar die toch een plek binnen de tool ecosphere hebben.
Keel (https://keel.sh)
Met Keel is het uitgangspunt dat een image bestaat (bijvoorbeeld afkomstig uit een bestaande workflow). Keel zorgt vervolgens voor deploy en update.
Kaniko (https://github.com/GoogleContainerTools/kaniko)
Met het Google tool Kaniko is het mogelijk om container images binnen een Kubernetes cluster te maken. Het voordeel ten opzichte van de standaard manier van Docker images opbouwen is dat hiervoor toegang tot de Docker daemon nodig is (oftewel: root access). Bij Kaniko is deze afhankelijkheid er niet.
Datawire Telepresence (https://www.telepresence.io/)
Met Telepresence is het mogelijk om code in een Kubernetes cluster te debuggen door het op een lokaal ontwikkelstation te draaien. Telepresence is daarmee een proxy tussen het lokale ontwikkelstation en het Kubernetes cluster.
Overkill: Hashicorp Packer en Terraform
En dan is er nog de afdeling overkill, met hierin de tools Packer en Terraform van Hashicorp. Beide tools hebben hun eigen bereik en waarde, maar de combinatie van de twee maakt van DevOps hogere wiskunde.
Hashicorp heeft een suite van infrastructure-as-code tools beschikbaar, waaronder Vagrant, Vault en Consul. Packer is een tool om geautomatiseerd machine images mee te creëren. Hiermee lijkt het op het eerste gezicht meer geschikt voor virtuele machines, maar het is ook te gebruiken om Docker images mee te maken. Het voordeel van Packer is dat het geen Dockerfiles gebruikt: Packer ziet Docker als een container engine en genereert images zonder dat de gebruiker de ins-en-outs van Dockerfiles hoeft te doorgronden.
Met Packer alleen is er nog geen Kubernetes-applicatie: dat is waar Terraform (een ander tool van Hashicorp) nodig is. Met Terraform is het mogelijk een volledige omgeving te provisionen als code. De combinatie van Packer en Terraform maakt het mogelijk om from scratch een volledig Kubernetes cluster inclusief code op te zetten. Een voorbeeld van hoe dit zou kunnen werken is door Kelsey Hightower uitgewerkt op https://github.com/kelseyhightower/kubestack – maar deze oplossing heeft de wereld niet veroverd, aan de last modified dates te zien…