Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

STANDORT-TEAM

Unser codecentric Team am Standort Erfurt stellt sich vor

codecentric Team Erfurt

Willkommen im Team Erfurt

Consultant & Developer

<p>The container ecosystem changes virtualization and the way we work as software developers by providing us with new possibilities to build, distribute and run software. Docker and Kubernetes are surely the best-known technologies in this field. But a lot of other (new) tools and methods offer promising approaches to the subject as well. By now, it has become hard to keep an overview on what is out there and what serves which purpose.</p><h2>ContainerConf 2019: Getting an overview on container technologies</h2><p>Therefore, in mid-November, I attended the <a href="https://www.containerconf.de/" target="_blank">ContainerConf</a>  in Mannheim, Germany – a 4-day conference about containers, Docker, Kubernetes, and everything related to that. I learned about a lot of new and interesting concepts, tools and methodologies. In this blog post, I want to share some of my impressions with you and hopefully give you a helpful overview on the recent state of the art when it comes to container technologies.</p><p>The first thing I noticed is that the ContainerConf has a heavily interlinked sister conference: <a href="https://www.continuouslifecycle.de/" target="_blank">Continuous Lifecycle</a> . It takes place at the same time and at the same location. As the name suggests, this conference is all about Build Management, DevOps, Continuous Integration, Continuous Delivery, and so forth. So the topics of both conferences definitely share a common ground. A ticket is valid for both conferences, so one more reason to attend!</p><p><a href="https://media.graphassets.com/d3tAS3tdSwamfSPfzRH5"><img width="700" height="525" src="https://media.graphassets.com/d3tAS3tdSwamfSPfzRH5" alt="ContainerConf 2019 Congress Center Rosengarten" /></a> </p><h2>Workshops: Kubernetes and Microservices</h2><p>The first and the last day of the conference are workshop days. I attended one on each day and both were very helpful. <strong>“Introduction to Kubernetes”</strong> from <a href="https://twitter.com/erkuleswastaken" target="_blank">Erkan Yanar</a>  was a pleasent hands-on workshop. Together with Erkan, we explored the basics of Kubernetes (Pods, Deployments, ConfigMaps, Ingress, etc.). We also touched some more advanced topics like Helm and Prometheus at the end. The only downside of the workshop was, that it ended when it got really interesting.</p><p><strong>“Microservices – Architecture and Implementation with Kubernetes and Istio”</strong> was quite different because it was not a hands-on workshop. I was a bit skeptical about the format at first. I feared it would be a whole day of basically only listening to a talk. But <a href="https://twitter.com/ewolff" target="_blank">Eberhard Wolff</a>  is a skillful teacher and the workshop was also interactive. Instead of fiddling with technical details on each participant’s laptop, we spent more time with discussions about the design of our example project. The workshop was absolutely worthwhile, and you could feel that Eberhard has a vast amount of experience.</p><p>Besides the workshops, a conference also consists of numerous exciting presentations. I attended 12 talks with a wide variety of topics. I will only give you a more detailed summary about some of them and a condensed recap about the other ones.</p><h2>Keynote “Trajectory of Chaos Engineering”</h2><p>What a talk! I really enjoyed it. <a href="https://twitter.com/caseyrosenthal" target="_blank">Casey Rosenthal</a>  presented the basic idea (and need!) of Chaos Engineering and spiced it up with some insightful and funny anecdotes. “Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.” (<a href="http://principlesofchaos.org/" target="_blank">http://principlesofchaos.org/</a> ). Especially in distributed microservice architectures, it is hard to test (or even understand) the system behavior as a whole. Chaos Engineering is one approach to tackle the complexity of such systems. One of the key points is that it is proactive.</p><p>Casey proposed that Chaos Engineering is no longer the new kid on the block. It is already accepted and used in many companies. In his opinion, we will see a new trend soon: After CI (Continuous Integration) and CD (Continuous Deployment) we will have CV (Continuous Verification). In my understanding, you can think of Continuous Verification as the automated repetition of chaos experiments – neat idea!</p><h2>“Service Mesh – What the new infrastructure can do for Microservices” (Orig: “Service Mesh – Was die neue Infrastruktur für Microservices taugt”)</h2><p><a href="https://twitter.com/HannaPrinz" target="_blank">Hanna Prinz</a>  gave a very informative talk about service meshes. She started by presenting one big problem with distributed microservice architectures: Cross-cutting concerns like timeouts, routing, authorization, encryption, etc. You will need to implement/handle these in each of your microservices. This can be painful, especially if you use different technologies and programming languages in your microservices. The idea of a service mesh is to provide these features out-of-the-box for all your microservices. She then went on to explain in more detail how a service mesh can help you with observability, routing, resilience, and security.</p><p>For the demonstration part Hanna Prinz chose <a href="https://istio.io/" target="_blank">Istio</a> , currently the most well-known service mesh. But in her opinion <a href="https://linkerd.io/" target="_blank">Linkerd</a>  is often good enough and much more easy to install and handle than Istio. She would only recommend Istio if its flexibility and complexity is truly needed. Hanna and her colleagues built a website that gives a quick overview about service meshes. This website also includes a comparison of the different implementations. Definitely have a look: <a href="https://servicemesh.es/" target="_blank">servicemesh.es</a> </p><h2>“Infrastructure-as-Code with Pulumi: Better than all the others (like Ansible)?”</h2><p>In this talk my codecentric colleague <a href="https://www.codecentric.de/ueber-uns/team/jonas-hecht/" target="_blank">Jonas Hecht</a>  presented <a href="https://www.pulumi.com/" target="_blank">Pulumi</a> , a new tool for Infrastructure-as-Code (cloud provisioning, configuration management, application deployment, …). After a general introduction of Pulumi and some live demos, he also did a thorough comparison with Ansible. One of the main differences is that Pulumi is not declarative, but procedural. This, of course, allows a great deal of flexibility! With the disadvantage that this might lead to a very diverse set of infrastructure files.</p><blockquote><p>Nice Talk from my <a href="https://twitter.com/codecentric?ref_src=twsrc%5Etfw">@codecentric</a>  colleague <a href="https://twitter.com/jonashackt?ref_src=twsrc%5Etfw">@jonashackt</a>  about infrastructure-as-code with Pulumi.</p><p>Seems like Pulumi has some nice ideas, but is not really the holy grail of IaC it claims to be.<a href="https://twitter.com/hashtag/ConLi19?src=hash&ref_src=twsrc%5Etfw">#ConLi19</a>  <a href="https://twitter.com/hashtag/HypeDrivenDevelopment?src=hash&ref_src=twsrc%5Etfw">#HypeDrivenDevelopment</a>  <a href="https://t.co/3SjOowc12Q">pic.twitter.com/3SjOowc12Q</a> </p><p>— Bertram Vogel (@bertoverflow) <a href="https://twitter.com/bertoverflow/status/1194643393621766144?ref_src=twsrc%5Etfw">November 13, 2019</a> </p></blockquote><p></p><p>My impression was that Jonas is not yet convinced by Pulumi in its current state. It claims to be language-agnostic, but almost all examples are JavaScript at the moment. It claims to be multi-cloud, but this seems to be mainly AWS currently. Pulumi resources in its current form are basically just “Terraform Wrappers”. And the comparison against Ansible did also not yield a clear winner. But Jonas also admitted that a lot of these points stem from the fact that Pulumi is still very young. Thus, it also does not have a big community. Jonas definitely was impressed by how quickly he could get an AWS Fargate up-and-running by <a href="https://www.pulumi.com/crosswalk/aws/" target="_blank">Pulumi Crosswalk for AWS</a> !</p><h2>“Creating a fast Kubernetes Development Workflow”</h2><p>This talk from <a href="https://twitter.com/BastianHofmann" target="_blank">Bastian Hofman</a>  was not so much about a fancy new methodology or concept, but more about software craftsmanship: How to use Kubernetes not only for production but also for your development workflow (and in an efficient way). My main takeaways are:</p><ul><li>use <a href="https://helm.sh/" target="_blank">Helm</a> : Helm is the package manager for Kubernetes and makes it super easy to install applications in your Kubernetes cluster</li><li>Helm charts provides a templating mechanism and thus can also be used to configure your Kubernetes application for production, deployment, different branches without copy-pasting all your yaml-files</li><li>helpful Kubernetes-tooling:<ul><li><a href="https://kubeval.instrumenta.dev/" target="_blank">kubeval</a> : validate Kubernetes configuration files</li><li><a href="https://github.com/ahmetb/kubectx" target="_blank">kubectx + kubens</a> : easily switch between clusters and namespaces</li><li><a href="https://github.com/aylei/kubectl-debug" target="_blank">kubectl-debug</a> : would have loved to already know about this during the workshop. kubectl-debug will run a new container in a running pod so you can debug the other containers in that pod. This works because all containers in a pod share the same pid- and network-namespace.</li><li><a href="https://helm.sh/docs/glossary/#lint-linting" target="_blank">helm lint</a> : use this to validate your helm charts while editing them</li><li><a href="https://k9scli.io/" target="_blank">K9s</a> : this was actually not part of the talk, instead my colleague Dennis Effing showed me this wonderful piece of software. K9s is a CLI that greatly improves the interaction with Kubernetes clusters. Just install it and see for yourself!</li></ul></li></ul><h2>Quick recap about the other talks</h2><p>The following list summarizes what I personally found the most interesting in the remainder of the talks. It is not meant to be an exhaustive explanation, but just to give you some buzzwords or phrases to google if it sounds promising to you 😉</p><ul><li><strong>“Infrastructure as Microservices – Alternatives to the monolith Kubernetes” (Orig: “Infrastructure as Microservices – Alternativen zum Monolithen Kubernetes”)</strong> (Nils Bokermann, <a href="https://twitter.com/SandraParsick" target="_blank">Sandra Parsick</a> ): Do you really need all of Kubernetes? It basically is a whole datacenter and it is complex. Why not slowly only introduce the parts that you currently require? Central configuration management? <a href="https://www.consul.io/" target="_blank">Consul</a> . Reverse Proxy and Load Balancing? <a href="https://containo.us/traefik/" target="_blank">Traefik</a> . You get the idea 🙂<br /> <a href="https://media.graphassets.com/odWSlVfVRm6ZWCvh2fkG"><img loading="lazy" width="700" height="525" src="https://media.graphassets.com/odWSlVfVRm6ZWCvh2fkG" alt="ContainerConf 2019 Talk Infrastructure as Microservices" /></a> </li><li><strong>“Integration Tests with Containers”</strong> (<a href="https://twitter.com/xeraa" target="_blank">Philipp Krenn</a> ): You do not test the “real” datastore with Mocks and In-Memory-Databases. Embedded Databases (if available) and especially <a href="https://www.testcontainers.org/" target="_blank">Testcontainers</a>  provide a much better alterative for integration tests.</li><li><strong>“More flow: essential Techniques for Continuous Delivery” (Orig: “Mehr Flow: Essenzielle Techniken für Continuous Delivery”)</strong> (<a href="https://twitter.com/Ookami86" target="_blank">Johannes Seitz</a> ): Trunk-based development (when done right) is more in the spirit of Continuous Integration than feature branches. Have a second build-pipeline, that builds and tests with all your dependencies from LATEST. This might help to prevent big-bang-migrations to a newer framework-version or similar.</li><li><strong>“Helm – The Better Way to Deploy on Kubernetes”</strong> (<a href="https://www.codecentric.de/ueber-uns/team/reinhard-naegele/">Reinhard Nägele</a> ): <a href="https://helm.sh/blog/helm-3-released/" target="_blank">Helm is released in version 3</a> . The Tiller is gone. There is a <a href="https://helm.sh/docs/topics/v2_v3_migration/" target="_blank">migration guide</a>  and a <a href="https://github.com/helm/helm-2to3" target="_blank">migration plugin</a> .</li><li><strong>“The Importance of Fun in the Workplace”</strong> (<a href="https://twitter.com/holly_cummins" target="_blank">Holly Cummins</a> ): If you look in a room and everyone is having fun, the team is productive and on time! Germans are easily impressed by jokes. Ducks make everything funnier.</li><li><strong>“100x Jenkins and not a bit tired” (Orig: “100 x Jenkins und kein bisschen müde”)</strong> (Frederic Gurr): <a href="https://github.com/eclipse-cbi/jiro" target="_blank">Jiro</a>  is a cluster-based Jenkins infrastructure for projects hosted by the Eclipse Foundation. <a href="https://jsonnet.org/" target="_blank">Jsonnet</a>  is a simple JSON-extension, that allows (among others) real comments in JSON-files!</li><li><strong>“Cloud Native Transformation Patterns”</strong> (<a href="https://twitter.com/pini42" target="_blank">Pini Reznik</a> ): Cloud Native is not only about the infrastructure and architecture, it is also about the teams and the culture. They identified and described some common patterns of a Cloud Native transformation.</li><li><strong>“Tools to Build Container Images”</strong> (<a href="https://twitter.com/martoss13" target="_blank">Martin Höfling</a> , Patrick Harböck): There are more tools to build images than just “docker build”. Docker build has security and scalability problems. For small teams they recommend docker (still a valid choice), <a href="https://buildah.io/" target="_blank">Buildah</a>  or <a href="https://github.com/moby/buildkit" target="_blank">BuildKit</a>  (which is already available as an experimental feature in docker via <a href="https://docs.docker.com/buildx/working-with-buildx/" target="_blank">docker buildx</a> ). For multiple teams with a provided Kubernetes-Infrastructure: <a href="https://github.com/GoogleContainerTools/kaniko" target="_blank">Kaniko</a> , <a href="https://github.com/uber/makisu" target="_blank">Makisu</a> . And for something completely different (no Dockerfile!): <a href="https://bazel.build/" target="_blank">Bazel</a> , <a href="https://github.com/GoogleContainerTools/jib" target="_blank">Jib</a> , <a href="https://buildpacks.io/" target="_blank">Cloud Native Buildpacks</a> .</li></ul><h2>Conclusion</h2><p>I really enjoyed ContainerConf! Besides all the new input I got, the conference itself was very well organized. The venue was spacious and the catering was delicious (self-service sweets bar!). And it was also easy to get into some interesting conversations with other participants during the breaks. Thanks especially to <a href="https://twitter.com/spanneberg" target="_blank">Bastian</a> , <a href="https://www.codecentric.de/ueber-uns/team/jonas-hecht/" target="_blank">Jonas</a>  and <a href="https://twitter.com/SandraParsick" target="_blank">Sandra</a>  for the amazing evening on Wednesday! Most importantly, the conference allowed me to take a deep dive into the container ecosystem. I now have a much better understanding how certain bits and pieces work together and what are promising technologies to look out for. I hope you could also learn something new and if you have any questions, please write a comment – I’m happy to answer them!</p><p><a href="https://media.graphassets.com/wQmvTZ8ASZOqHJ0Zx4RX"><img loading="lazy" width="700" height="933" src="https://media.graphassets.com/wQmvTZ8ASZOqHJ0Zx4RX" alt="ContainerConf 2019 Water Tower Mannheim" /></a> </p>

Brave new container world – an overview

Senior IT Consultant

In diesem Artikel gehen wir darauf ein, wie mithilfe des Spring-Webflux-Projekts eine reaktive Anwendung erstellt werden kann und welche Herausforderungen dieser Ansatz mit sich bringt. Wir erläutern kurz, was Kotlin Coroutines sind und zeigen, wie die Herausforderungen des Reactive Programmings mit Spring Webflux mit einer Implementierung in Kotlin Coroutines umgangen oder zumindest abgefedert werden können.

## Reactive Programming mit Spring Webflux
In einem [vorangegangenen Artikel](https://www.codecentric.de/wissens-hub/blog/reactive-programming-spring-webflux) haben wir eine Einführung ins Reactive Programming und das Spring-Webflux-Projekt gegeben. Den in diesem Artikel genutzten Beispiel-Controller wollen wir hier nochmal aufgreifen. Dieser wurde vollständig reaktiv mit Java, der Reactive Streams API und Spring Webflux implementiert:

```java
@RestController
class CustomerController {

   private final CustomerRepository repository;

   CustomerController(final CustomerRepository repository) {
       this.repository = repository;
   }

   @PostMapping("/customer")
   Mono<Customer> createNewCustomer(@RequestBody Mono<CustomerCreationRequest> request) {
      return request.flatMap( dto -> 
            repository.save(new Customer(dto.firstName(), dto.lastName()))
      );
   }
}

record CustomerCreationRequest(String firstName, String lastName) {}

@Repository
interface CustomerRepository extends ReactiveCrudRepository<Customer, Long> {

   Flux<Customer> findByFirstNameAndLastName(String firstName, String lastName);
}
```

Durch ein HTTP POST gegen die URL `/customer` kann hier ein neues `Customer`-Objekt erzeugt und in der Datenbank persistiert werden. Das Ganze passiert reaktiv, da in der Methode `createNewCustomer()` das `Mono` für den Eingangsparameter `request` mithilfe der `flatMap()`-Methode mit dem reaktiven Repository und dessen `save()`-Methode verknüpft wird. Dadurch kann Spring Webflux dann einen HTTP Request ohne jegliche Blocking IO verarbeiten. 

Es wird in diesem Beispiel jedoch auch deutlich, welche Nachteile das Reactive Programming mit sich bringt. Der Code ist für viele Entwickler komplizierter zu schreiben und zu verstehen. Im Gegensatz zu einem klassischen, imperativen Ansatz, bei dem der Code von oben nach unten ausgeführt wird, muss der Entwickler hier in Verkettungen von Streams denken. Und diese Verkettungen können deutlich komplexer werden als in diesem einfachen Beispiel, wie wir am Ende dieses Artikels zeigen werden. Diese Art des Denkens ist für viele Entwickler ungewohnt und stellt damit zunächst eine Hürde für die Nutzung von Reactive Programming dar. Wir werden im Folgenden zeigen, wie man mithilfe von Kotlin Coroutines das gewohnte imperative Programmiermodell auch für die Implementierung reaktiver Anwendungen nutzen kann.

## Kotlin und Coroutines
Das zentrale Element für die Implementierung von Nebenläufigkeit in Kotlin sind die sog. *Coroutines*. Dabei handelt es sich, ähnlich wie bei Threads, um Programmabläufe, die parallel zueinander ausgeführt werden können. Im Gegensatz zu Threads sind Coroutines aber sehr leichtgewichtig und können zu Tausenden nebeneinander gestartet werden. Das ist möglich, weil Coroutines mithilfe sog. *Worker-Threads* implementiert werden. Dabei gibt es einen festen Pool von Threads, der sich um die Ausführung aller Coroutines im Hintergrund kümmert. Eine Coroutine kann an bestimmten Punkten während der Ausführung unterbrochen werden und zu einem späteren Zeitpunkt von einem anderen Thread weiter bearbeitet werden. Wann diese Thread-Wechsel passieren ist für den Entwickler transparent und wird von der Kotlin Runtime entschieden. Für einen tiefergehenden Einblick in Coroutines verweisen wir auf den Einführungsartikel [hier](https://www.codecentric.de/wissens-hub/blog/einfuehrung-in-kotlin-coroutines) im Blog.

### Controller mit Suspend Function
Fest verbunden mit Coroutines sind in Kotlin die sog. *suspend functions*. Diese Funktionen werden innerhalb einer Coroutine ausgeführt und erlauben es, unterbrochen zu werden (deshalb *suspend*). Die zugehörige Coroutine wird dabei dann auch unterbrochen, was letztendlich bedeutet, dass sie keinem Thread aus dem Thread-Pool mehr zugeordnet wird. Diesen Mechanismus können wir uns zunutze machen, um Reactive Programming mit einem imperativen Programmiermodell umzusetzen. Betrachten wir dazu die Implementierung unseres Beispiel-Controllers mit Kotlin:

```kotlin
@RestController
class CustomerController(
   private val repository: CustomerRepository
) {

   @PostMapping("/customer")
   suspend fun createNewCustomer(@RequestBody request: Flow<CustomerCreationRequest>): Customer {
      val dto = request.single()
      return repository.save(Customer(dto.firstName, dto.lastName))
   }
}

data class CustomerCreationRequest(val firstName: String, val lastName: String)

@Repository
interface CustomerRepository : CoroutineCrudRepository<Customer, Long>{

   fun findByFirstNameAndLastName(firstName: String, lastName: String): Flow<Customer>
}
```

Neben der etwas kompakteren Schreibweise, die uns Kotlin erlaubt, fällt gleich auf, dass die beiden Monos verschwunden sind. Außerdem wird auch die `flatMap()`-Methode nicht mehr verwendet. Die Methode `createNewCustomer()` gibt direkt das `Customer`-Objekt zurück. Trotz dieser Änderungen ist der Controller vollständig non-blocking. Der Trick ist hier das Schlüsselwort `suspend`. Dadurch kann diese Methode immer dann unterbrochen werden, wenn sie eine andere *suspend function* aufruft. Und das wiederum erlaubt es Spring Webflux (genauer, der *InvocableHandlerMethod*), den Aufruf dieser Methode in einem `Mono` zu verpacken. Das resultierende `Mono` emittiert also genau dann das `Customer`-Objekt, wenn obige *suspend function* von der Coroutine abgearbeitet wurde. Dadurch können wir als Entwickler uns das `Mono` als Rückgabetyp ersparen. 

Eine weitere Auffälligkeit ist der Typ des Parameters `request`. Dieser hat sich von `Mono` zu `Flow` geändert. Dabei handelt es sich um eine Abstraktion von Kotlin, die als eine Vereinigung der Reactive Streams Publisher `Mono` und `Flux` betrachtet werden kann. Anders als in der Reactive Streams API wurde `Flow` aber vor allem deshalb eingeführt, um zu erlauben, dass Coroutines asynchron einen Stream von Objekten austauschen können (siehe auch <a href="https://kotlinlang.org/docs/flow.html" target="_blank">hier</a> in der Kotlin-Dokumentation). In unserem Fall möchten wir in der Methode `createNewCustomer()` darauf warten, dass ein `CustomerCreationRequest` verfügbar wird. Der Aufruf der `single()`-Methode (ebenfalls eine *suspend function*) wird die Ausführung daher so lange unterbrechen, bis ein Request-Objekt (durch Spring Webflux) verfügbar wird. Anschließend wird die Ausführung innerhalb der Coroutine fortgesetzt, ein `Customer`-Objekt erzeugt und die suspend function `save()` des Repositorys aufgerufen. Auch dieser Aufruf wird wieder zu einer Unterbrechung führen, bis die Persistierung in der Datenbank abgeschlossen ist. Erst dann wird die Coroutine weiterlaufen und das persistierte `Customer`-Objekt als Ergebnis zurückliefern. Der Sourcecode sieht fast wie in einem klassischen imperativen Programmiermodell aus, durch die Möglichkeit der Unterbrechung der Methode ist aber eine Ausführung wie in einem Reactive-Ansatz möglich. Der Entwickler muss sich damit aber gedanklich kaum beschäftigen, was die Komplexität deutlich reduziert.

### Komplexeres Beispiel
Um die mögliche Reduktion der Komplexität nochmal deutlicher zu zeigen, möchten wir abschließend unser Beispiel durch eine komplexere Abfrage ergänzen. Dabei sollen alle `Customer`-Objekte anhand ihrer Kundengruppe abgefragt werden. Der reaktive Java-Code dieser Abfrage sieht wie folgt aus:

```java
@GetMapping("/search/customerGroup/{customerGroup}")
Flux<Customer> findByCustomerGroup(@PathVariable final String customerGroup) {
   return webClient.getCustomerGroup(customerGroup)
           .flatMapMany(group ->
                   Flux.concat(
                           group.entries()
                                   .stream()
                                   .map(entry -> repository.findByFirstNameAndLastName(entry.firstName(), entry.lastName()))
                                   .toList()
                   )
           );
}
```

Zunächst wird mithilfe eines Webclients eine REST-API eines anderen Services aufgerufen, um den Namen der Kundengruppe zu einer Liste von Kundennamen aufzulösen. Diese Liste kann dann anschließend benutzt werden, um aus dem oben bereits genutzten Repository die tatsächlichen `Customer`-Objekte auszulesen. Sowohl der Aufruf der REST-API als auch der Aufruf des Repositorys sind dabei non-blocking und nutzten `Mono` bzw. `Flux` als Rückgabewert. Diese müssen dann wieder miteinander verkettet werden (diesmal mit den `flatMapMany()`- und `Flux.concat()`-Methoden). Der ungeübte Entwickler wird hier einen Augenblick brauchen, um genau zu verstehen, wie die einzelnen Aufrufe zusammenhängen. Und selbst viele geübte Entwickler werden diesen Code nicht ohne Weiteres runterschreiben können. Die Kotlin-Implementierung dieses Beispiels ist nicht nur einfacher zu verstehen, sondern einer klassischen imperativen Implementierung auch deutlich ähnlicher:

```kotlin
@GetMapping("/search/customerGroup/{customerGroup}")
suspend fun findByCustomerGroup(@PathVariable customerGroup: String): Flow<Customer> {
   val group = webClient.getCustomerGroup(customerGroup)
   return group
       .entries
       .map { repository.findByFirstNameAndLastName(it.firstName, it.lastName) }
       .merge()
}
```

Hier gibt es noch eine Besonderheit. In Kotlin hat es sich als Best Practice etabliert, dass eine Methode mit Rückgabewert `Flow` keine *suspend function* sein sollte, sondern stattdessen unmittelbar den `Flow` zurückgibt. Eventuelle Aufrufe von blockierenden oder *suspending functions* innerhalb dieser Methode werden dabei in die Ausführung des `Flow` selbst verschoben. Dies lässt sich in obiger Methode leicht erreichen, indem man den Methodenkörper in einen `flow { ... }` Builder einbettet und die `return`-Anweisung durch ein `emitAll()` ersetzt. Durch Kotlins ausdrucksstarke Syntax fällt diese Änderung kaum auf, ist für einen Entwickler des klassischen, imperativen Ansatzes dennoch weniger vertraut. Aus unserer Sicht sind für eine Controller-Methode beide Varianten akzeptable Lösungen:

```kotlin
@GetMapping("/search/customerGroup/{customerGroup}")
fun findByCustomerGroup(@PathVariable customerGroup: String) = flow {
   val group = webClient.getCustomerGroup(customerGroup)
   emitAll(group
      .entries
      .map { repository.findByFirstNameAndLastName(it.firstName, it.lastName) }
      .merge())
}
```

## Fazit
Wir hoffen, wir konnten mit den obigen Beispielen zeigen, dass in Java ein Reactive-Ansatz wie Spring Webflux eine kognitive Belastung für die Entwickler mitbringen kann und dass es möglich ist, diese durch die Benutzung von Kotlin Coroutines bzw. *suspend functions* zu reduzieren. Gerade Entwicklern, die bisher eher im Blocking-IO-Umfeld Erfahrung gesammelt haben (z. B. mit Spring MVC), kann der Umstieg in die Non-blocking-Welt vereinfacht werden, wenn man dabei die von Kotlin angebotenen Konzepte nutzt.

Ein tolles Paar: Spring Webflux und Kotlin Coroutines

Reactive Programming mit Spring Webflux

Spring Boot & Apache CXF – Logging & Monitoring mit Logback, Elasticsearch, Logstash & Kibana

Ansible zaubert Spring Boot Apps auch auf Windows

Spring Boot & Apache CXF – SOAP ohne XML?

Spring Boot & Apache CXF – SOAP-Webservices testen

Spring Boot & Apache CXF – XML-Validierung und Custom SOAP Faults

Spring Boot & Apache CXF – Von 0 auf SOAP mit dem cxf-spring-boot-starter

Simplifying Spring Boot GraalVM Native Image builds with the native-image-maven-plugin

Spring Boot & Apache CXF – Logging & Monitoring with Logback, Elasticsearch, Logstash & Kibana

Running Spring Boot apps as GraalVM Native Images

Taming the Hybrid Swarm: Initializing a Mixed OS Docker Swarm Cluster Running Windows & Linux Native Containers with Vagrant & Ansible

Running Spring Boot Apps on Docker Windows Containers with Ansible: A Complete Guide incl Packer, Vagrant & Powershell

Running Spring Boot Apps on Windows with Ansible

Running Spring Boot GraalVM Native Images with Docker & Heroku

Continuous cloud infrastructure with Ansible, Molecule & TravisCI on AWS

Continuous Infrastructure with Ansible, Molecule & TravisCI

Spring Boot on Heroku with Docker, JDK 11 & Maven 3.5.x

Test-driven infrastructure development with Ansible & Molecule

<p>The Pipeline-as-Code pattern is implemented by most CI/CD platforms today. So what could be the next evolutionary step? Based on GitHub Actions, the article outlines why open-source Pipeline-as-Code Building Blocks will take your pipelines to the next level.</p><h2>GitHub Actions – blog series</h2><p>Part 1: <a href="https://blog.codecentric.de/en/2021/02/github-actions-pipeline/">GitHub Actions CI pipeline: GitHub Packages, Codecov, release to Maven Central & GitHub</a> <br /> Part 2: <a href="https://blog.codecentric.de/en/2021/03/github-container-registry/">Publishing Docker images to GitHub Container Registry with GitHub Actions</a> <br /> Part 3: Stop re-writing pipelines! Why GitHub Actions drive the future of CI/CD</p><h2>Isn’t it just another CI/CD tool?</h2><p>While migrating many of my open-source projects to GitHub Actions, one thought gradually came to my mind over the last few months: I realized I was working with a kind of next-generation CI/CD platform. Which I didn’t get at first <strong>since GitHub Actions is just another CI/CD tool right?</strong> Only a different syntax for our pipeline, which shouldn’t be considered a really big step …</p><p>But then it slowly became clear to me: <strong>it’s all about this “Actions” thing!</strong> And I started to think about what I experienced in my professional career using CI/CD tooling as a key piece of my toolbelt. But to really explain what my thoughts are all about, I need to go back in time more than 10 years. 🙂 Please excuse me if I leave out a lot of great tools on this journey. I only wanted to sketch out an idea rather than provide <a href="https://github.com/ligurio/awesome-ci" target="_blank">a comprehensive overview of all CI/CD platforms available</a> . So I will focus on the ones that have been most popular in my life as a software engineer.</p><h2>Going back over a decade in time: the first wave of CI/CD platforms</h2><p>Let’s start with some time in 2007 when I was in the middle of my higher-education studies. Since I was doing a work-study course, I was thrown into practical application really early. And I’m still honored that I was able take part in the so-called “Frameworks Team” as a student already. On this team, <strong>I was able to watch the introduction of the first CI server quite closely</strong>: back then, my colleague Xavier reported about the first installation of a Hudson server, his eyes shining with delight.</p><p><img width="1024" height="768" src="https://media.graphassets.com/mQ6cKHqlSa6kPWFmVhQ4" alt="the 3 waves of CICD platforms that lead to the Pipeline-as-Code Building Blocks pattern" /></p><p>Logo sources: <a href="https://www.jenkins.io/" target="_blank">Jenkins logo</a> , <a href="https://travis-ci.com/" target="_blank">TravisCI logo</a> , <a href="https://about.gitlab.com/press/press-kit/" target="_blank">GitLab logo</a> , <a href="https://github.com/" target="_blank">GitHub Actions logo</a> </p><p>This thing was so popular, <a href="https://medium.com/swlh/hudson-is-retiring-the-end-of-a-jenkins-story-9cee866135ab" target="_blank">it even received the Duke’s Choice Award at JavaOne 2008</a> . Forced to fork the project because of Oracle’s purchase of Sun Microsystems, the project was renamed to “<a href="https://www.jenkins.io/" target="_blank">Jenkins</a> ” in January 2011. And <strong>I guess we all know Jenkins in some form</strong>. It is by far the most widely used CI/CD platform, I guess. And there are good reasons for that! I was in the role of a software architect in a project back in 2013, where my soon-to-be colleague <a href="https://twitter.com/denschu" target="_blank">Dennis Schulte</a>  showed us how to use <a href="https://github.com/jenkinsci/job-dsl-plugin" target="_blank">the Jenkins Job DSL plugin</a>  to circumvent the maintainance hell brought about by hundreds of manually created Jenkins jobs.</p><h2>Pipeline-as-Code: the second wave of CI/CD platforms</h2><p>When referring to the time before the release of the Job DSL plugin, I think it’s fair to speak of the <em>“first wave of CI/CD platforms”</em>. The Job DSL plugin – and later the <a href="https://www.jenkins.io/blog/2016/02/29/jenkins2-alphas/" target="_blank">Jenkins 2.0 pipelines project in 2016</a>  – are part of the second wave of CI/CD platforms. But Jenkins wasn’t the driver behind this next wave, really. Released as early as 2013, the <a href="https://en.wikipedia.org/wiki/Travis_CI" target="_blank">TravisCI project</a>  aimed to provide CI/CD services free for open source projects. This was a huge step! <strong>Bringing together TravisCI with GitHub, the resulting setup could be seen as a forerunner of modern software development processes.</strong> And they didn’t stop there. I first realized how elegant and simple CI/CD pipelines could be when I joined codecentric in 2015. Encouraged to use our off-project time to build and play with open source projects, I started to create my first projects incorporating this setup. And using Travis felt like a revelation to me! I only had to write a few lines of code and had my pipelines test and build my application.</p><p>Back then I always considered the software development process inside enterprise companies to be separate from the one used in open-source projects. My “reasoning” was: <em>Well, Travis is so simple and easy to use because they don’t need to deal with “all that enterprisey stuff”</em>. But soon something began to work in the back of my head. And finally in 2018 I realized that <strong><a href="https://docs.gitlab.com/ee/ci/" target="_blank">GitLab CI</a>  brought the power & elegance of CI/CD pipelines to the enterprise that I only knew from TravisCI</strong>. I was really disillusioned by the implementation of the Pipeline-as-Code pattern by Jenkins 2.0 in 2017. Back then we tried to implemend it at a customer project (<a href="https://twitter.com/m_p_dus" target="_blank">Marco</a> , I hear you 🙂 ). But GitLab made me realize what this might look like. I also assume that it’s not an easy task to introduce a big application like Jenkins to a new pattern like Pipeline-as-Code. Especially when you’re striving to be completely downward-compatible, as Jenkins 2.0 was aiming to be. I was so convinced by the solution GitLab brought into the game, I wrote lots of articles about it (e.g. <a href="https://blog.codecentric.de/en/2018/05/gitlab-ci-pipeline/">this one</a>  and <a href="https://www.heise.de/select/ix/2018/8/1533431466220024" target="_blank">this one</a> ). And I recommended this great platform to my customers.</p><h2>GitLab CI brought Pipeline-as-Code to the enterprise</h2><p>GitLab CI also solved an issue I had with most Pipeline-as-Code platforms. Released in <a href="https://about.gitlab.com/2019/01/22/gitlab-11-7-released/" target="_blank">version 11.7 at the beginning of 2019</a> , GitLab CI made a huge step forward again. They introduced <a href="https://docs.gitlab.com/ee/ci/yaml/#include" target="_blank">the include keyword</a>  into their pipeline syntax. With this great addition, <strong>it was possible to write re-usable pipeline templates</strong> (I know by the time also Jenkins pipelines made this possible, but I didn’t find their solution as elegant).</p><p>I remember being inside a customer project in 2019 where we faced a migration of several hundred projects to GitLab. Having a set of tested and high-quality pipeline templates at hand was a key success factor in the project. And I guess it is in many companies, because we all love DevOps. And we all want to do Microservices. But many customers <a href="https://www.ufried.com/blog/microservices_fallacy_10_microliths/" target="_blank">aren’t able to fill their projects with Fullstack DevOps superstars only</a> . <strong>So having some people focussing on writing really good CI/CD templates is not a bad idea</strong>.</p><p>To sum up, I would say that roughly the time from 2013 to 2019 could be seen as <em>the second wave of CI/CD platforms</em>. All platforms began to focus on the Pipeline-as-Code pattern and some implemented it better than others (as we’re accustomed to in IT history 🙂 ).</p><h2>GitHub Actions kick off the third wave of CI/CD platforms</h2><p>At the end of 2019 <a href="https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/" target="_blank">GitHub announced the availability of GitHub Actions</a>  I didn’t really have the time back then to dig into it deeper. One thing that also kept me from doing so was the thought: <strong>“Oh, just another CI/CD platform. So who cares?”</strong> I already wrote about the fact I was forced to look into it at the end of 2020. This was <a href="https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing" target="_blank">when TravisCI stopped broad support for open-source projects</a> . I needed (and still need) to move all my open-source repositories to GitHub Actions. See the <a href="https://blog.codecentric.de/en/2021/02/github-actions-pipeline/">“The problem with TravisCI” paragraph in one of my last articles</a> . This migration also forced me to really take a closer look at the platform. I realized that GitHub Actions easily adapted everything that was already great in other platforms. <strong>But it adds one piece that sets it apart from the others.</strong> And it’s right there in the name: Actions! But wait. What are those Actions?</p><p><img loading="lazy" width="1024" height="1158" src="https://media.graphassets.com/aDjuZzEuQZGqaZufsWFD" alt="Open Source Pipeline-as-Code Building Blocks pattern idea outlined" /></p><p>To get a first understanding, you may want to have a look at <a href="https://github.com/marketplace?type=actions" target="_blank">the GitHub Actions Marketplace</a> . The Actions listed there are either provided by GitHub itself, or they are developed by other companies and the community. In both cases they are available as open-source projects on GitHub. These Actions help you solve common problems that occur while writing CI/CD pipelines. And <strong>they are assemblable like the famous Lego blocks and finally form your CI/CD pipelines.</strong> Read that once again! As already said, for me it was the first thought when I heard about the Pipeline-as-Code pattern: How are we supposed to reuse stuff we write here? Do we need to write this release pipeline over and over again? How was this Sonar analysis supposed to be written again? And finally: how can we deploy our app to this shiny new cloud service using Infrastructure-as-Code? <strong>Many aspects of such questions are already covered by an Action available.</strong> And they ultimately reduce the lines of code needed inside our CI/CD pipelines drastically. Especially when compared to other tools.</p><h2>It’s all about the Actions</h2><p>Just insert these few lines describing the chosen Action and go for it. Let’s assume you need a changelog for your artifact releases. Simply use the <a href="https://github.com/metcalfc/changelog-generator" target="_blank">metcalfc/changelog-generator</a>  Action in your GitHub Actions workflow (or another of the dozens of available changelog Actions):</p><div>

```yaml
      - name: Generate changelog
        uses: metcalfc/changelog-generator@v0.4.4
        with:
          myToken: ${{ secrets.GITHUB_TOKEN }}
```

</div><p>Maybe you need to<a href="https://blog.codecentric.de/en/2021/02/github-actions-pipeline/"> set up a JDK to build and deploy to Maven Central</a>  (configuring a pre-defined <code>settings.xml</code> under the hood also). Just use <a href="https://github.com/actions/setup-java" target="_blank">GitHub’s setup-java Action</a> :</p><div>

```yaml
      - name: Set up settings.xml for Maven Central Repository
        uses: actions/setup-java@v1
        with:
          java-version: 11
          server-id: oss.sonatype.org
          server-username: MAVEN_USERNAME
          server-password: MAVEN_PASSWORD
          gpg-private-key: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }}
          gpg-passphrase: MAVEN_GPG_PASSPHRASE
```

</div><p>And what about said shiny cloud provider and some Infrastructure-as-Code tooling? Let’s say we use <a href="https://www.pulumi.com/" target="_blank">Pulumi</a>  to provision our infrastructure in <a href="https://azure.microsoft.com/en-us/" target="_blank">Azure</a> . There’s a great <a href="https://github.com/pulumi/actions" target="_blank">Pulumi Action</a>  available:</p><div>

```yaml
      - uses: pulumi/actions@v1
        with:
          command: up
        env:
          ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }}
          ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }}
          ARM_CLIENT_SECRET: ${{ secrets.ARM_CLIENT_SECRET }}
          ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }}
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
```

</div><p>You also don’t need to worry that your pipelines will spontaneously start to behave completely differently. As you may have noticed, <strong>every action has a specific version number</strong>. So upgrades are made explicit (and should be also automated with a tool like <a href="https://github.com/renovatebot/renovate" target="_blank">renovate</a>  🙂 ). I guess this outlines the idea behind Actions aka Pipeline-as-Code Building Blocks 🙂 And in the rare event that there’s no Action for your use case: You can write and publish your own Actions, of course.</p><h2>Open-source Pipeline-as-Code Building Blocks</h2><p>OK, maybe I’m overly enthusiastic here. But for me the “Actions” in GitHub Actions kick off the next level (or wave) in the evolution of CI/CD platforms! Finally <strong>we’re able to really reduce boilerplate code in our pipelines</strong>. And we don’t have to establish a new team to write re-usable templates for us. We can simply pick the ones needed. Additionally these building blocks aren’t only used by our own company. There’s even a big community of people using the Actions, reporting issues, pushing the development of it further, in other words: bringing <strong>all the benefits of open-source software into the creation of CI/CD pipelines</strong>. A logical step after the introduction of Pipeline-as-Code. Since I see it as a kind of pattern, I would like to name it: “Pipeline-as-Code Building Blocks”.</p><p>This is maybe an unusual post of mine: nearly no example code! But as I’ve already written about GitHub Actions (and will continue to write about them in the future), I hope you’ll forgive me. <strong>I simply needed to put an emphasis on the huge step this tooling represents for the CI/CD world.</strong> I don’t think that GitHub will be the only one that’s adopting the pattern of “Pipeline-as-Code Building Blocks” in the future, though. But so far only GitHub really implements it this broadly. So if you haven’t done so already: take a look at GitHub Actions for your next project. And then stop re-writing your CI/CD pipelines. 🙂</p>

Stop re-writing pipelines! Why GitHub Actions drive the future of CI/CD

GitHub Actions CI pipeline: GitHub Packages, Codecov, release to Maven Central & GitHub

<p>You may have heard about all the benefits of Cloud Native Buildpacks?! But Paketo’s pack CLI depends on Docker. So what about our Kubernetes-based CI systems, where we might not have a Docker daemon available?</p><h2>Cloud Native Buildpacks – blog series</h2><p>Part 1: <a href="https://blog.codecentric.de/en/2020/11/buildpacks-spring-boot/"> Goodbye Dockerfile: Cloud Native Buildpacks with Paketo.io & layered jars for Spring Boot</a> <br /> Part 2: Cloud Native Buildpacks / Paketo.io in GitLab CI without Docker & pack CLI</p><p>I was recently thrown into a customer project in which everything is based on <a href="https://docs.gitlab.com/ee/ci/" target="_blank">GitLab CI</a> . Which is a great tool, although I tend to favour GitHub Actions right now <a href="https://blog.codecentric.de/en/2021/03/github-actions-nextgen-cicd/" target="_blank">because of their great reusable Pipeline-as-Code Building Blocks</a> . But I was keen to work with the latest GitLab CI version to see how it has progressen since the last time I had used it intensively. And really <strong>the first thing we wanted to do in GitLab was to use Cloud Native Buildpacks / Paketo.io to build our container images!</strong> Remember <a href="https://blog.codecentric.de/en/2020/11/buildpacks-spring-boot/" target="_blank">that the Dockerfile is dead</a>  – so today, we shouldn’t need to write and maintain them anymore.</p><p>Well, hasn’t this cool Auto DevOps feature been introduced by GitLab CI? And <a href="https://buildpacks.io/docs/tools/gitlab/" target="_blank">there’s already a Buildpacks integration ready!</a>  As stated in the docs our <code>.gitlab-ci.yml</code> only needs to look like this:</p><div>

```javascript
include:
  - template: Auto-DevOps.gitlab-ci.yml
 
variables:
  AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED: "true"
```

</div><p>But soon we looked stupidly at this build log:</p><div>

```javascript
Building Cloud Native Buildpack-based application with builder heroku/buildpacks:18...
ERROR: failed to build: failed to fetch builder image 'index.docker.io/heroku/buildpacks:18': Cannot connect to the Docker daemon at tcp://localhost:2375. Is the docker daemon running?
```

</div><p>What was this all about?</p><h2>GitLab CI with unprivileged Kubernetes Runners – and no Docker socket!</h2><p>GitLab has been setup by the great folks over at <a href="https://www.codecentric.de/leistungen/managed-services" target="_blank">codecentric cloud</a> , where our customers just rent it as a managed service. In a state-of-the-art setup this GitLab uses <a href="https://aws.amazon.com/eks/" target="_blank">Amazon EKS</a>  to run its <strong>builds on Kubernetes-based Runners</strong>. Quite early in the process, Daniel from codecentric cloud made one thing clear: in the default setup <strong>we wouldn’t be able to access the Docker daemon socket inside our containers</strong> running inside the Kubernetes cluster. And we also wouldn’t have any containers in privileged mode (aka Docker in Docker or <code>docker:dind</code>). And that should be the case, if we take a look at all the security risks being introduced otherwise.</p><p>As this could be seen as a common setup, <strong>it shouldn’t be a big deal to use Paketo.io & Cloud Native Buildpacks in this scenario right?!</strong> Therefore we should lift our gaze from the <a href="https://docs.gitlab.com/ee/topics/autodevops/" target="_blank">Auto DevOps feature</a>  and get our hands dirty! Let’s write our own GitLab CI yaml files! Commonly the basic ingredient of using Paketo.io and Cloud Native Buildpacks is to utilize <a href="https://buildpacks.io/docs/tools/pack/" target="_blank">pack CLI</a> . Here’s an example command which is usually everything you need in order to build and publish an OCI container image:</p><div>

```javascript
pack build microservice-api-spring-boot:latest \
    --builder paketobuildpacks/builder:base \
    --path .
```

</div><p><a href="https://buildpacks.io/docs/tools/pack/#install" target="_blank">Installing pack CLI</a>  inside our .gitlab-ci.yml and simply using it to build our container images plunged us into an already known trap:</p><div>

```javascript
$ pack build $CI_REGISTRY_IMAGE:latest --builder paketobuildpacks/builder:base --path .
ERROR: failed to build: failed to fetch builder image 'index.docker.io/paketobuildpacks/builder:base': Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
```

</div><p>These errors finally reminded me of my colleague <a href="https://twitter.com/omegapolice" target="_blank">Raphael</a> . Right after writing about <a href="https://blog.codecentric.de/en/2020/11/buildpacks-spring-boot/" target="_blank">all those merits of Cloud Native Buildpacks</a>  he tore me out of my reveries:</p><blockquote><p>“Hey Jonas, that’s really cool stuff! I love it. But do we really need to have Docker installed in order to use Paketo with its nice and shiny pack CLI? What about my CI systems? I love Kubernetes and <a href="https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-in-your-builds" target="_blank">don’t want to introduce all those security risks</a>  to my pipelines…”</p></blockquote><p>But stepping back and refraining from using Cloud Native Buildpacks wasn’t an option to us! I also thought about <a href="https://docs.gitlab.com/runner/executors/kubernetes.html#using-kaniko" target="_blank">using kaniko as stated in the GitLab CI docs</a> . But <a href="https://github.com/GoogleContainerTools/kaniko" target="_blank">kaniko</a>  needs <code>Dockerfiles</code>. And not needing to write and maintain them anymore is the whole point here…</p><h2>Directly using Paketo’s lifecycle instead of Docker</h2><p>But finally it came to me. <strong>I had already read about this issue with pack CLI.</strong> I came across it writing the first article of this blog series: <a href="https://github.com/buildpacks/pack/issues/564" target="_blank">github.com/buildpacks/pack/issues/564</a> . The initial question nails it:</p><blockquote><p>There are many users who are starting to not have Docker installed on their systems because there are other alternatives that let them create containers in a secure way <strong>as they typically run these containers on remote systems (e.g. kubernetes clusters)</strong>. […] Pack, although not depending on docker build […] does require Docker to be running on your container.</p></blockquote><p>Followed by a big discussion there was <a href="https://github.com/buildpacks/pack/issues/413#issuecomment-565165832" target="_blank">only one comment</a>  that included a hint on how to deal with the issue:</p><blockquote><p>If you’re looking to build images in CI (not locally), I’d encourage you to <strong>use the lifecycle directly for that</strong>, so that you don’t need Docker. <a href="https://github.com/tektoncd/catalog/blob/main/task/buildpacks/0.3/buildpacks.yaml" target="_blank">Here’s an example</a> </p></blockquote><p>The comment refers to the <a href="https://tekton.dev/" target="_blank">Tekton</a>  implementation on <a href="https://github.com/tektoncd/catalog/blob/main/task/buildpacks/0.3/buildpacks.yaml" target="_blank">how to use buildpacks in a Kubernetes environment</a> . And that brought us onto the right path. Here we can get a first clue about what is referred to as <em>“to use the lifecycle directly”</em>. The crucial point there is the usage of the <code>command: ["/cnb/lifecycle/creator"]</code>. We finally found the lifecycle mentioned above. And there’s also a good documentation about this command which can be found <a href="https://github.com/buildpacks/rfcs/blob/main/text/0026-lifecycle-all.md#usage" target="_blank">in this Cloud Native Buildpacks RFC</a> .</p><h2>A good base image: paketobuildpacks/builder:base</h2><p>So how can we get closer to a working <code>.gitlab-ci.yml</code>?<br /> <strong>It’s always a good way to start as simple as possible.</strong> Digging <a href="https://github.com/tektoncd/catalog/blob/main/task/buildpacks/0.3/buildpacks.yaml" target="_blank">into the Tekton implementation,</a>  you’ll see that the lifecycle command is executed inside an environment defined in <code>BUILDER_IMAGE</code>. This variable is defined as <em>The image on which builds will run (must include lifecycle and compatible buildpacks)</em>.</p><p>Maybe that sounds familiar?!<br /> <strong>Can’t we simply pick the builder image <a href="https://hub.docker.com/r/paketobuildpacks/builder" target="_blank">paketobuildpacks/builder:base</a>  from our pack CLI command?</strong> Let’s try this locally on our workstation before committing too much noise into our GitLab. Before running the build, we need to choose an application project we want to turn into a container image. I created an example Spring Boot app on <a href="https://gitlab.com/jonashackt/microservice-api-spring-boot" target="_blank">gitlab.com/jonashackt/microservice-api-spring-boot</a>  which you can clone. Or use your own app, if you’d like. Having the application project available locally, we can simply spin up a container based on the Paketo builder image <code>paketobuildpacks/builder</code>:</p><div>

```javascript
docker run --rm -it -v "$PWD":/usr/src/app -w /usr/src/app paketobuildpacks/builder bash
```

</div><p>With this command we mount the application’s source code into the container in order to have it available for the Paketo lifecycle. Now, inside the container we can <strong>try to run the Paketo lifecycle directly</strong> with:</p><div>

```javascript
/cnb/lifecycle/creator -app=. microservice-api-spring-boot:latest
```

</div><p>I only used the <code>-app</code> parameter of <a href="https://github.com/buildpacks/rfcs/blob/main/text/0026-lifecycle-all.md#usage" target="_blank">the <code>creator</code> command’s</a>  many possible parameters. That should be okay for many cases since most of them have quite good defaults. I configured the app path as the default one at <code>/workspace</code> doesn’t hold our application source. Instead it’s the current directory. Also we need to define an <code>image-name</code> at the end, which will be used as the resulting container image name.</p><p>The execution of the lifecycle should trigger a normal Paketo build using Cloud Native Buildpacks! <strong>But this time we did not need pack CLI</strong> 🙂</p><h2>The first .gitlab-ci.yml</h2><p>As now we know how to run the Paketo lifecycle directly, we can craft our <code>.gitlab-ci.yml</code>. Using some <a href="https://docs.gitlab.com/ee/ci/variables/predefined_variables.html" target="_blank">GitLab CI predefined variables</a>  the command could look like this:</p><div>

```yaml
/cnb/lifecycle/creator -app=. $CI_REGISTRY_IMAGE:latest
```

</div><p>Choosing the wrong image name could lead to a breaking Buildpack process analyser step and no image gets pushed to the GitLab Container Registry!<br /> So let’s craft our first <code>.gitlab-ci.yml</code> like this:</p><div>

```yaml
image: paketobuildpacks/builder

stages:
  - build

build-image:
  stage: build
  script:
    - /cnb/lifecycle/creator -app=. $CI_REGISTRY_IMAGE:latest
```

</div><p>Commiting this to our repository in GitLab <strong>should already start a GitLab CI build using Buildpacks!</strong> Yay! 🙂<br /> The only problem is that it might run into an error like this:</p><div>

```yaml
    ===> ANALYZING
    ERROR: failed to get previous image: connect to repo store "gitlab.yourcompanyhere.cloud:4567/yourgroup/microservice-api-spring-boot:latest": GET https://gitlab.yourcompanyhere.cloud/jwt/auth?scope=repository%3Ayourgroup%2Fmicroservice-api-spring-boot%3Apull&service=container_registry: DENIED: access forbidden
    Cleaning up project directory and file based variables 00:01
    ERROR: Job failed: command terminated with exit code 1
```

</div><h2><em>docker login</em> without Docker</h2><p>Using the build image <code>paketobuildpacks/builder:base</code> we don’t have the command <code>docker</code> available inside our Kubernetes Runners. So we can’t <a href="https://docs.gitlab.com/ee/user/packages/container_registry/#authenticate-by-using-gitlab-cicd" target="_blank">login to GitLab Container Registry as described in the official docs</a> . That’s why we run into the <code>DENIED: access forbidden</code> error, because our pipeline has no access to the GitLab Container Registry.</p><p>Luckily my colleague <a href="https://twitter.com/m_p_dus" target="_blank">Marco</a>  gave me the hint that there’s the approach <a href="https://stackoverflow.com/a/46422186/4964553" target="_blank">described in this stackoverflow answer</a> . <strong>Instead of using <code>docker login</code> we can create the Docker configuration file <code>~/.docker/config.json</code> ourselves.</strong> So let’s create it containing our GitLab Container Registry’s login information. This way <a href="https://github.com/buildpacks/spec/blob/main/platform.md#registry-authentication" target="_blank">the Paketo build will pick them up as stated in the docs</a> :</p><blockquote><p>If <code>CNB_REGISTRY_AUTH</code> is unset and a docker config.json file is present, the lifecycle SHOULD use the contents of this file to authenticate with any matching registry.</p></blockquote><p>Inside our <code>.gitlab-ci.yml</code> creating a correct <code>~/.docker/config.json</code> could look like this:</p><div>

```yaml
    before_script:
      - mkdir ~/.docker
      - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_JOB_TOKEN\"}}}" >> ~/.docker/config.json
```

</div><p>Again be sure to use the handy <a href="https://docs.gitlab.com/ee/ci/variables/predefined_variables.html" target="_blank">GitLab CI predefined variables</a>  like <code>$CI_REGISTRY</code> (the GitLab Container Registry url) and the variables <code>$CI_REGISTRY_USER</code> & <code>$CI_JOB_TOKEN</code>, which contain the credentials.</p><h2>Our final .gitlab-ci.yml</h2><p>So bringing it all together, our <code>.gitlab-ci.yml</code> finally looks like this:</p><div>

```yaml
image: paketobuildpacks/builder

stages:
  - build
 
# We somehow need to access GitLab Container Registry with the Paketo lifecycle
# So we simply create ~/.docker/config.json as stated in https://stackoverflow.com/a/41710291/4964553
before_script:
  - mkdir ~/.docker
  - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_JOB_TOKEN\"}}}" >> ~/.docker/config.json

build-image:
  stage: build
  script:
    - /cnb/lifecycle/creator -app=. $CI_REGISTRY_IMAGE:latest
```

</div><p>Here’s the example project’s <a href="https://gitlab.com/jonashackt/microservice-api-spring-boot/-/blob/main/.gitlab-ci.yml" target="_blank">fully working <code>.gitlab-ci.yml</code></a> .<br /> <strong>Our builds should now run successfully, using Paketo/Buildpacks without pack CLI and Docker</strong>:</p><p><img width="1024" height="911" src="https://media.graphassets.com/PILwGSBhTNSLxiY0Lln5" alt="GitLab CI running Paketo Buildpack build without pack CLI unprivileged" /></p><p>The example project also has <a href="https://gitlab.com/jonashackt/microservice-api-spring-boot/-/jobs/1679213328" target="_blank">the full build log available here</a> , if you’re interested.</p><h2>Great to see Cloud Native Buildpacks / Paketo.io working in GitLab CI without Docker & pack CLI!</h2><p>I’m absolutely glad to see <a href="https://blog.codecentric.de/en/2020/11/buildpacks-spring-boot/" target="_blank">my favourite container build solution</a>  working together with a state-of-the-art CI/CD setup like GitLab featuring Kubernetes runners! Being able to use Cloud Native Buildpacks / Paketo.io without the Docker daemon or pack CLI, <strong>enables a much broader usage of this absolutely great technology.</strong> It’s no problem to stay with pack CLI locally, if you have Docker installed. But you now know what it means to <strong>use the lifecycle directly</strong>! Besides Tekton there’s also another gread CI/CD tooling using this trick: <a href="https://github.com/pivotal/kpack" target="_blank">kpack</a> .<br /> Hopefully, I will find the time to write about it in the near future 🙂<br /> <a href="https://www.codecentric.de/karriere/jobs/cloud-native-entwicklerin?utm_campaign=PeSo%20Blog%20to%20Job&utm_source=cc_blog&utm_medium=display&utm_content=cloud_native_developer_und_consultant" target="_blank"><img loading="lazy" width="660" height="220" src="https://media.graphassets.com/2mSd0KsrS96mi0kzeeEg" alt="Mitglieder für unsere Gilde gesucht! Jetzt der Gilde als Cloud Native Developer und Consultant (w/d/m) beitreten" /></a> </p><p> </p>

Cloud Native Buildpacks / Paketo.io in GitLab CI without Docker & pack CLI

Goodbye Dockerfile: Cloud Native Buildpacks with Paketo.io & layered jars for Spring Boot

<p>Tired of bumping into Docker Hub’s rate limiting? Why not give the GitHub Container Registry a try? Right now it’s in public beta but it already looks great, especially in combination with GitHub Actions.</p><h2>GitHub Actions – blog series</h2><p>Part 1: <a href="https://blog.codecentric.de/en/2021/02/github-actions-pipeline/">GitHub Actions CI pipeline: GitHub Packages, Codecov, release to Maven Central & GitHub</a> <br /> Part 2: Publishing Docker images to GitHub Container Registry with GitHub Actions<br /> Part 3: <a href="https://blog.codecentric.de/en/2021/03/github-actions-nextgen-cicd/">Stop re-writing pipelines! Why GitHub Actions drive the future of CI/CD</a> </p><h2>What’s the problem with Docker Hub?</h2><p>Recently I’ve been running into <a href="https://www.docker.com/increase-rate-limit" target="_blank">Docker Hub’s new rate limiting</a>  more and more often. So regardless which CI system I use, I find myself looking into a log file at something like this:</p><div>

```bash
Unable to find image 'hello...
You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit.\nSee 'docker run --help'.\n"
```

</div><p>or this</p><div>

```bash
ERROR: toomanyrequests: Too Many Requests.
```

</div><p>So <strong>I thought of using an alternative container registry</strong> that doesn’t expose such a limit. Coincidentally I was updating my example project, which shows <a href="https://github.com/jonashackt/spring-boot-graalvm" target="_blank">how to use GraalVM with Spring</a> . I learned that Oracle moved their GraalVM Docker image from <code>oracle/graalvm-ce</code> (already producing a 404) from <a href="https://hub.docker.com" target="_blank">hub.docker.com</a>  to a place at <a href="https://github.com/graalvm/container/pkgs/container/graalvm-ce" target="_blank">github.com/graalvm/container/pkgs/container/graalvm-ce</a> . The resulting image has the coordinates <code>ghcr.io/graalvm/graalvm-ce</code> and is served by the <em>GitHub Container Registry</em>. Wow, <strong>I didn’t even know that GitHub had a registry!</strong> But <a href="https://github.blog/2020-09-01-introducing-github-container-registry/" target="_blank">in late 2020 they introduced it</a>  as part of their GitHub Packages offering (if you want to see the “normal” Packages in action, you can take a sneak peek <a href="https://blog.codecentric.de/en/2021/02/github-actions-pipeline/" target="_blank">here where I show how to publish Maven artifacts</a> ).</p><p><img width="1024" height="407" src="https://media.graphassets.com/03cH3SDmS2KC76q7dxBc" alt /></p><p>Logo sources: <a href="https://github.com/" target="_blank">GitHub & GitHub Actions & GitHub Packages logo</a> , <a href="https://www.docker.com/" target="_blank">Docker logo</a> </p><p>Soon I realized that <a href="https://medium.com/faun/migrating-my-docker-images-to-the-github-container-registry-9f304ccf0aaa" target="_blank">more people started to migrate their Docker images</a>  to <a href="https://docs.github.com/en/packages/guides/pushing-and-pulling-docker-images" target="_blank">the new GitHub Container Registry</a> :</p><blockquote><p>GitHub Container Registry is currently in public beta and subject to change. During the beta, storage and bandwidth are free. To use GitHub Container Registry, you must enable the feature preview.</p></blockquote><p>The GitHub Container Registry <a href="https://stackoverflow.com/a/66368787/4964553" target="_blank">will ultimately supersede the already existing Packages Docker Registry</a> .</p><h2>All I wanted was: docker run hello-world</h2><p>I hadn’t touched <a href="https://github.com/jonashackt/molecule-ansible-docker-aws" target="_blank">my beloved molecule showcase project</a>  for a while (wow, my blog about <a href="https://blog.codecentric.de/en/2019/01/ansible-molecule-travisci-aws/" target="_blank">Continuous cloud infrastructure with Ansible, Molecule & TravisCI on AWS</a>  is already older than two years). So I finally needed to upgrade to the latest <a href="https://github.com/ansible-community/molecule" target="_blank">molecule</a>  module system with separate drivers not being shipped inside the core anymore. The upgrade really went super smoothly. Right until I hit the Docker Hub rate limiting problem in the final testinfra test case . 🙁 It was really all about a failing <code>docker run hello-world</code>!! <strong>What the hell?!</strong></p><p>So I thought about publishing my own hello-world image to the GitHub Container Registry. Maybe even others would bump into the same problem. And this would give me the chance to get to know this new registry. 🙂 In the end all I wanted was something I could simply use like this:</p><div>

```java
docker run ghcr.io/jonashackt/hello-world
```

</div><h2>A simple Go-based executable</h2><p>The <a href="https://github.com/docker-library/hello-world" target="_blank">original hello-world image from Docker Hub</a>  uses a small executable to print a text. I decided to leverage <a href="https://golang.org/" target="_blank">Go</a>  in order to create a reasonably small executable myself. Every piece of code I use throughout this post <a href="https://github.com/jonashackt/docker-hello-world" target="_blank">is also available on GitHub</a> .</p><p>So let’s start with a ultra simple <a href="https://github.com/jonashackt/docker-hello-world/blob/main/hello-world.go" target="_blank">hello-world.go</a> :</p><div>

```golang
package main
 
import "fmt"
 
func main() {
	fmt.Println("Hello from Docker on GitHub Container Registry!\nThis message shows that your installation appears to be working correctly.")
}
```

</div><p>Building and running a Go program is easy. You only need to have <a href="https://golang.org/doc/install" target="_blank">the Go compiler installed</a>  on your machine. On my Mac I used homebrew and did a <code>brew install go</code>. Now we can build the program with</p><div>

```golang
go build hello-world.go
```

</div><p>This will produce a <code>hello-world</code> executable that we can run with <code>./hello world</code>.</p><h2>A multi-stage build for our GO program</h2><p>As we only need to have the Go compiler present to build the binary, we should implement a Docker multi-stage build. The <a href="https://hub.docker.com/_/golang" target="_blank">official Go image</a>  is quite huge:</p><div>

```bash
$ docker images
golang     latest     861b1afd1d13   7 days ago     862MB
```

</div><p>Therefore we should leverage <a href="https://docs.docker.com/develop/develop-images/multistage-build/" target="_blank">a multi-stage build</a>  inside of our <a href="https://github.com/jonashackt/docker-hello-world/blob/main/Dockerfile" target="_blank">Dockerfile</a> :</p><div>

```java
# We need a golang build environment first
FROM golang:1.16.0-alpine3.13
 
WORKDIR /go/src/app
ADD hello-world.go /go/src/app
 
RUN go build hello-world.go
 
# We use a Docker multi-stage build here in order that we only take the compiled go executable
FROM alpine:3.13
 
COPY --from=0 "/go/src/app/hello-world" hello-world
 
ENTRYPOINT ./hello-world
```

</div><p>The second “run” image is based on <a href="https://hub.docker.com/_/alpine" target="_blank">the same alpine image</a>  as the builder image containing the Go compiler. So let’s now simply build and run our image:</p><div>

```bash
$ docker build . --tag hello-world
$ docker run hello-world
Hello from Docker on GitHub Container Registry!
This message shows that your installation appears to be working correctly.
```

</div><p>The resulting image is around <code>7.55MB</code> which should be small enough for our use cases.</p><h2>List of steps how to publish to GitHub Container Registry with GitHub Actions</h2><p>In order <a href="https://docs.github.com/en/packages/guides/pushing-and-pulling-docker-images" target="_blank">to publish a container image on GitHub Container Registry</a>  using GitHub Actions, we have to do the following steps:</p><p><strong>1. Activate improved container support</strong><br /> <strong>2. Create a personal access token (PAT) and a repository secret</strong><br /> <strong>3. Create GitHub Actions workflow and login to GitHub Container Registry using the PAT</strong><br /> <strong>4. Publish (push) Container image to GitHub Container Registry & link it to our repository</strong><br /> <strong>5. Optional: Make your image publicly accessible</strong></p><h2>1. Activating improved container support</h2><p>This step is only needed while the GitHub Container Registry is in beta phase. In order to use the new Container Registry feature, <a href="https://docs.github.com/en/packages/guides/enabling-improved-container-support" target="_blank">we need to activate it in our account first</a> . Therefore head to your GitHub account’s settings menu und click on <code>Feature preview</code>:</p><p><img loading="lazy" width="1024" height="428" src="https://media.graphassets.com/d143IpnPQNaKFZgUYaKV" alt="Feature preview GitHub profile settings" /></p><p>In my account there was only one feature I could choose from: the <strong>improved container support feature</strong> we need to enable to have GitHub Container Registry ready:</p><p><img loading="lazy" width="1024" height="367" src="https://media.graphassets.com/NDIe8FOsQIuwtW4zXopZ" alt="Activate improved container support" /></p><h2>2. Creating a personal access token (PAT) and a repository secret</h2><p>Right now (in beta) <a href="https://docs.github.com/en/packages/guides/pushing-and-pulling-docker-images#authenticating-to-github-container-registry" target="_blank">we can’t use the <code>GITHUB_TOKEN</code> in GitHub Actions to authenticate to the GitHub Container Registry</a> . So we need to create a personal access token (PAT). But keep in mind <a href="https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token" target="_blank">what the docs state</a> :</p><blockquote><p>PATs can grant broad access to your account. We recommend selecting only the necessary read, write, or delete package scope when creating a PAT to authenticate to the container registry.</p></blockquote><p>Create a PAT in <code>Settings/Developer settings</code> <code>Personal access tokens</code> and click on <code>Generate new token</code>. Here you need to select <code>read:packages</code>, <code>write:packages</code> and <code>delete:packages</code> scopes like this:</p><p><img loading="lazy" width="1024" height="707" src="https://media.graphassets.com/tnp0PBw1TGlhmJc2KGtI" alt="Create a personal access token in GitHub" /></p><p>Having created the PAT, we can move on to create a new repository secret inside our GitHub repository that contains our Go program and <code>Dockerfile</code>. To create a repository secret, head to your repository’s settings tab and click on <code>Secrets</code>. There you should be able to create a new repository secret:</p><p><img loading="lazy" width="1024" height="626" src="https://media.graphassets.com/j34Zc4ErTrKMxpnMRdya" alt="Create a new repository secret containing the PAT" /></p><h2>3. Creating GitHub Actions workflow and logging into GitHub Container Registry using the PAT</h2><p>With both PAT and repository secret set up, we can now create a new (or choose an existing) GitHub Actions workflow. After the usual checkout action, we should set our secret as an environment variable. The example project’s workflow file <a href="https://github.com/jonashackt/docker-hello-world/blob/main/.github/workflows/publish.yml" target="_blank">.github/workflow/publish.yml</a>  looks like this:</p><div>

```yaml
name: publish

on: [push]

jobs:
  publish-hello-world-image:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Build the hello-world Docker image
      run: |
        echo $CR_PAT | docker login ghcr.io -u YourAccountOrGHOrgaNameHere --password-stdin
      env:
        CR_PAT: ${{ secrets.CR_PAT }}
```

</div><p>Be sure to use your account or GitHub organization name instead of <code>YourAccountOrGHOrgaNameHere</code>. This should successfully do the login to the GitHub Container Registry.</p><h2>4. Publishing (Pushing) Container image to GitHub Container Registry & linking it to our repository</h2><p>So we’re already approaching the final steps. Now we should have everything in place to push our container image to the GitHub Container Registry. Therefore we need to tag our image correctly while building it. The tag’s pattern must adhere to <code>ghcr.io/OWNER/IMAGE_NAME:latest</code>. Inside the example project’s <a href="https://github.com/jonashackt/docker-hello-world/blob/main/.github/workflows/publish.yml" target="_blank">.github/workflow/publish.yml</a>  it looks like this:</p><div>

```yaml
        docker build . --tag ghcr.io/jonashackt/hello-world:latest
        docker run ghcr.io/jonashackt/hello-world:latest
        docker push ghcr.io/jonashackt/hello-world:latest
```

</div><p>This is already enough to push our image!</p><p>As the image is published as a GitHub account global package, it isn’t linked with our repository and thus won’t be displayed there, nor will it use the <code>README.md</code> as description. In order to automatically link our image to our GitHub repository, we need to add a specific <code>LABEL</code> into our <a href="https://github.com/jonashackt/docker-hello-world/blob/main/Dockerfile" target="_blank">Dockerfile</a> . It should contain the URL to our repository like this:</p><div>

```java
LABEL org.opencontainers.image.source="https://github.com/jonashackt/docker-hello-world"
```

</div><p>Having added this label to our <code>Dockerfile</code>, the image package automatically gets linked to our repository:</p><p><img loading="lazy" width="1024" height="754" src="https://media.graphassets.com/mdbqELJR9KTpyp44D4Ow" alt="The image gets linked to the repository using the LABEL" /></p><p>Also, the image becomes visible on our repository’s main page:</p><p><img loading="lazy" width="1024" height="597" src="https://media.graphassets.com/9Jty5hcIQtOGT09GqDIS" alt="The image gets visible on the repositories main page" /></p><h2>5. Optional: Making your image publicly accessible</h2><p>By default <a href="https://docs.github.com/en/packages/guides/configuring-access-control-and-visibility-for-container-images" target="_blank">, our container image is private on the GitHub Container Registry</a> . To make it publicly accessible, we need to move to our user account or GitHub organization page. For my account, this is <a href="https://github.com/jonashackt?tab=packages" target="_blank">https://github.com/jonashackt?tab=packages</a> :</p><p><img loading="lazy" width="1024" height="414" src="https://media.graphassets.com/ExAO5dcQlGhGgeC9vEgM" alt="images are shown as packages on the account level" /></p><p>Click on the container image published (which looks the same as a normal GitHub package) and then go to <code>Package Settings</code>. In the <code>Danger Zone</code>, click on <code>change visibility</code> and choose <code>Public</code>:</p><p><img loading="lazy" width="1024" height="698" src="https://media.graphassets.com/ZedLoXURVmbxKImy3V8Q" alt="package settings for public visibility" /></p><p>Now we should finally be able to pull and run our image! Simply run <code>docker run ghcr.io/jonashackt/hello-world</code>:</p><div>

```java
$ docker run ghcr.io/jonashackt/hello-world
Unable to find image 'ghcr.io/jonashackt/hello-world:latest' locally
latest: Pulling from jonashackt/hello-world
ba3557a56b15: Already exists
8d624a13b642: Pull complete
Digest: sha256:c88996d21c33ed08a76decc2b53e109bbc601d0fa1e444f24682250c5d406aa1
Status: Downloaded newer image for ghcr.io/jonashackt/hello-world:latest
Hello from Docker on GitHub Container Registry!
This message shows that your installation appears to be working correctly.
```

</div><h2>Give the GitHub Container Registry a try!</h2><p>I didn’t really want to create a <code>hello-world</code> image myself in the first place. But hey! Working with the GitHub Container Registry is fun and you should consider it for your next project. In this article we have seen how to create a small example program and build it using a Docker multi-stage build. The activation of the new feature and the creation of a personal access token (PAT) are the prerequisites to using the Container Registry right now in beta phase. I guess both won’t be necessary anymore soon.</p><p>Using GitHub Actions, we only need to log in using our PAT which we can store in a repository secret. The <code>LABEL org.opencontainers.image.source</code> links our image to our repository after we pushed it using a GitHub Actions workflow of choice. Finally we define our image as publicly accessible if we want it to be. That’s it already! Now it’s time to move your images from Docker Hub to GitHub Container Registry I guess. 🙂 And if you ever need a <code>hello-world</code> image, you know where to find it …</p>

Publishing Docker images to GitHub Container Registry with GitHub Actions

Spring Boot & Apache CXF – How to SOAP in 2016

Spring Boot & Apache CXF – Testing SOAP Web Services

Spring Boot & Apache CXF – XML validation and custom SOAP faults

Spring Boot & Apache CXF – SOAP on steroids fueled by cxf-spring-boot-starter

Senior Solution Architect

<p><span>In this blog post, I will demonstrate how you can deploy an application to AWS Fargate using the AWS CDK. The WordPress software is used, which introduces some requirements. So Elastic File System and Aurora Serverless database will be deployed, too.</span></p><p><span>As an example, think of a website for an event that allows for registration at a specific time. Or there are thousands of people trying to register for a very limited course that many want to attend. Everyone knows the registration likely is available during a 10 minute time frame twice a year as it is instantly fully booked. Now they are hitting the page reload button. An approach to counter such situations is a service named AWS Fargate, which provides computing resources. You don’t have to choose instance types or any other unit in advance. Amazon provides resources as needed by the workload. This is very useful if the usage pattern of the deployed application is extremely volatile and you don’t want to spend time evaluating the best amount of computing resources to handle the load. Maybe there is a database that has to be scaled with your workload.</span></p><h2>Overview</h2><p>To get an idea about the moving parts we need to create, I will provide an image showing the amazon products involved, more details will follow.</p><p><img src="https://media.graphassets.com/1xJHJoqCQFWqqkcwMb1o" alt="overview AWS fargate" width="708" height="341" /></p><h2><h2>Bootstrap</h2><p>Before we start, you have to create the project files. For your convenience, the AWS CDK provides a command to generate some boilerplate code. Install the CDK and create an empty directory. After that, initialize your project.</p>

```
npm install -g aws-cdk
mkdir project && cd project
cdk init --language=python --generate-only
```

<h2><h2>Docker build and push</h2><p>First, we build the Fargate task in the private section. The task serving the WordPress site needs an image, from which the container can be created from. <a href="https://hub.docker.com/_/wordpress" target="_blank"><span>Prebuilt images</span></a> <span> are available for download from the official docker hub. That image will be used to spin up a container in an ECS cluster.</span></p><p><span>You will notice that the <strong>default</strong> images have a maximum HTTP post size of <strong>2 MB</strong> configured, which is not enough if you want to upload larger plugins or media files. To configure the parameters affecting that limit, you have to create or modify some files inside the image. If you do this in local docker or in Kubernetes, you simply mount a file or a config to the container. Fargate does not have such a mechanism. It would be quite nice to mount a file from s3. Amazon is currently <a href="https://github.com/aws/containers-roadmap/issues/56">working on it</a> , but the feature is not completed yet. Another option would be to place a file in an EFS volume. But the AWS CDK <a href="https://github.com/aws/aws-cdk/issues/9496">lacks an upload feature</a>  as known from s3. A different approach is to build your own images, based on the official ones. They can be uploaded to ECR for later usage. To build an image in AWS CDK, you need the context path and a dockerfile:</span></p>

```
# docker context directory
docker_context_path = os.path.dirname(__file__) + "../../src"

# upload images to ecr
nginx_image = ecr_assets.DockerImageAsset(
    self, "Nginx",
    directory=docker_context_path,
    file="Docker.nginx",
)

wordpress_image = ecr_assets.DockerImageAsset(
    self, "Php",
    directory=docker_context_path,
    file="Docker.wordpress",
)
```

<p>That’s it! The AWS CDK detects whether a build is needed and will upload the resulting image to <a href="https://aws.amazon.com/ecr/">ECR</a> . To configure PHP to allow more than the 2 MB limit for file upload, create a file containing</p>

```
file_uploads = On
memory_limit = 64M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 600
```

<p>and include the path in your dockerfile.</p><p>As you can see in the CDK code above, there are two docker images. I prefer to have a single process per container as this is a cleaner approach. The downside is greater complexity when it comes to communication between the processes.</p><p>To allow Nginx to send messages to the PHP process, it needs a network address and port. To allow some local test, you can configure the endpoint at build time:</p>

```
ARG upstream_wordpress_php=localhost

COPY ./nginx/conf.d/http.conf /etc/nginx/conf.d/default.conf

RUN echo -e "upstream wordpress_php {\n  server $upstream_wordpress_php:9000;\n}\n" \
    > /etc/nginx/conf.d/upstream.conf
```

<p>This allows the usage of a local <a href="https://github.com/dhenne/aws-cdk-fargate-aurora-wordpress-example/blob/main/src/docker-compose.yml">docker-compose.yml</a> , to enable a local spin-up of a WordPress site. In Fargate all containers of a task are reachable through the loopback device. Amazon uses a network mode called <a href="https://aws.amazon.com/blogs/compute/task-networking-in-aws-fargate/">awsvpc</a> . Now that we have an image, we are able to define our Fargate task. The image object can be passed directly to the task definition. The AWS CDK takes care of all tasks needed to have the correct image used.</p><h2><h2>Fargate task definition</h2>

```
event_task = ecs.FargateTaskDefinition(self, "WordpressTask")

app_container = event_task.add_container(
    "Php",
    image=ecs.ContainerImage.from_docker_image_asset(wordpress_image)
)
nginx_container = event_task.add_container(
    "Nginx",
    image=ecs.ContainerImage.from_docker_image_asset(nginx_image)
)
```

<p><strong>Note:</strong> The strings to name the resources are meaningless. In AWS, a common pattern is to name your resources with capitalized letters.</p><p>Now you can create an ECS cluster and place your task definition on it. At this point, it is very important to specify the Fargate version to <strong>1.4</strong>. People at AWS have decided that the “latest” platform version <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html">in fact means the “penultimate” version</a> .</p>

```
cluster = ecs.Cluster(
    self, 'ComputeResourceProvider',
    vpc=properties.vpc
)

wordpress_service = ecs.FargateService(
    self, "InternalService",
    task_definition=event_task,
    platform_version=ecs.FargatePlatformVersion.VERSION1_4,
    cluster=cluster,
)
```

<p>Now you would be able to start a task. There’s one thing more to do. We have to specify a <a href="https://github.com/aws/aws-cdk/issues/10113">port mapping for each container</a> , even though we may not need it. This can be done using the following.</p>

```
nginx_container.add_port_mappings(
    ecs.PortMapping(container_port=80)
)
```



```
app_container.add_port_mappings(
    ecs.PortMapping(container_port=9000)
)
```

<h2><h2>Database</h2><p><span>You can now start a task, but there are still some parts missing. We do need some persistence for files and structured data (SQL). As stated before, an Aurora Serverless database provides the SQL service for our task. The definition is straight forward:</span></p>

```
database = rds.ServerlessCluster(
    self, "WordpressServerless",
    engine=rds.DatabaseClusterEngine.AURORA_MYSQL,
    default_database_name="WordpressDatabase",
    vpc=properties.vpc,
    scaling=rds.ServerlessScalingOptions(
        auto_pause=core.Duration.seconds(0)
    ),
    deletion_protection=False,
    backup_retention=core.Duration.days(7),
    removal_policy=core.RemovalPolicy.DESTROY,
)
```

<p>A secret and a database are automatically created. To pass the values to the WordPress container, you can reference them directly. The AWS CDK creates appropriate roles and permissions to apply to the task that allows the retrieval of secret values.</p>

```
app_container = event_task.add_container(
    "Php",
    environment={
        'WORDPRESS_DB_HOST': database.cluster_endpoint.hostname,
        'WORDPRESS_TABLE_PREFIX': 'wp_'
    },
    secrets={
        'WORDPRESS_DB_USER':
            ecs.Secret.from_secrets_manager(database.secret, field="username"),
        'WORDPRESS_DB_PASSWORD':
            ecs.Secret.from_secrets_manager(database.secret, field="password"),
        'WORDPRESS_DB_NAME':
            ecs.Secret.from_secrets_manager(database.secret, field="dbname"),
    },
    image=ecs.ContainerImage.from_docker_image_asset(wordpress_image)
)
```

<h2><h2>Elastic File System</h2><p><span>WordPress is an application written in PHP and extendable by plugins. All that functionality is relying on a writable filesystem, where the PHP user can place its files, so everything can be done through the web interface. Therefore you need a shared filesystem that can be mounted to the container running the PHP process. Since </span><a href="https://aws.amazon.com/de/about-aws/whats-new/2020/04/amazon-ecs-aws-fargate-support-amazon-efs-filesystems-generally-available/" target="_blank"><span>last year</span></a> <span>, attaching an EFS to Fargate task definitions has generally been available. More details about persistent storage in amazon ECS is available in the <a href="https://aws.amazon.com/blogs/compute/task-networking-in-aws-fargate/">aws documentation</a> . Create your EFS storage and define a volume.</span></p>

```
file_system = efs.FileSystem(
    self, "WebRoot",
    vpc=properties.vpc,
    performance_mode=efs.PerformanceMode.GENERAL_PURPOSE,
    throughput_mode=efs.ThroughputMode.BURSTING,
)
```



```
wordpress_volume = ecs.Volume(
    name="WebRoot",
    efs_volume_configuration=ecs.EfsVolumeConfiguration(
        file_system_id=file_system.file_system_id
    )
)
```

<p>Later that volume can be used to extend your task definition.</p>

```
event_task = ecs.FargateTaskDefinition(
    self, "WordpressTask",
    volumes=[wordpress_volume]
)
```

<p>Now, this volume is available to container mounts in your task definition. WordPress needs write access to that volume. Read permissions are sufficient for Nginx.</p>

```
nginx_container_volume_mount_point = ecs.MountPoint(
    read_only=True,
    container_path="/var/www/html",
    source_volume=wordpress_volume.name
)
nginx_container.add_mount_points(nginx_container_volume_mount_point)
```



```
container_volume_mount_point = ecs.MountPoint(
    read_only=False,
    container_path="/var/www/html",
    source_volume=wordpress_volume.name
)
app_container.add_mount_points(container_volume_mount_point)


```

<h2><h2>Networking</h2><p>The final part of the deployment is about network connectivity. You may have noticed the VPC parameter before. We can create this VPC or use a preexisting one. In my example repository you have the whole network-related resources, separated in a different stack, to be reusable by several other stacks. You can have a look at the <a href="https://github.com/dhenne/aws-cdk-fargate-aurora-wordpress-example/blob/main/cdk_stacks/network.py">file</a> . There are two different network types created and endpoints of a load balancer are placed in the public subnet. The result looks like the following picture.</p><p><img loading="lazy" width="738" height="701" src="https://media.graphassets.com/7aaZ1hC5SzGa9yuHewiR" alt="context path and docker file" /></p><p>The VPC and the load balancer are then passed to the WordPress stack as property objects. You can also create a parent stack around the constructs, but I think you get the point. Note that there is an upper limit of stacks per account. If you have too many, you can use nested stacks.</p><p> </p><p>To allow the Fargate tasks to connect to the elastic filesystem and the Aurora Serverless database, add them to the appropriate security groups:</p>

```
database.connections.allow_default_port_from(wordpress_service)
file_system.connections.allow_default_port_from(wordpress_service)
```

<p>In this blog post, an application load balancer is used to provide an endpoint to which the outside users can connect. The Fargate tasks are automatically added to the targets of this load balancer as they are created. You simply have to define a listener and configure your load balancer watch for the WordPress service. You also can apply some rules to the listener affecting request routing. But there is only one site delivered at the moment. If the WordPress site is not initialized yet, then it is redirecting requests to an installation page. Therefore the load balancer health checks have to accept that redirect as successful. To achieve that, the HTTP Code 302 can be added to the list of acceptable return codes.</p>

```
http_listener = properties.load_balancer.add_listener(
    "HttpListener",
    port=80,
)

http_listener.add_targets(
    "HttpServiceTarget",
    protocol=elbv2.ApplicationProtocol.HTTP,
    targets=[wordpress_service],
    health_check=elbv2.HealthCheck(healthy_http_codes="200,301,302")
)
```

<h2><h2>Deploy</h2><p>When you are done defining your stacks, all resources can be deployed using the deploy command. This takes a few minutes and outputs information about created instances. You can read about the whole process <a href="https://docs.aws.amazon.com/cdk/latest/guide/apps.html">here</a> . In short, the CDK command synthesizes the code to cloud assemblies, which contain the images and cloudformation templates. After creation, the artifacts are uploaded to AWS.</p>

```
cdk deploy --require-approval never --all
```

<p>I have stripped out the progress bar and other elements of less relevance. You can see the ExternalDNSName the deployed WordPress instance is reachable at. In production scenarios, you should use HTTPS certificates and a suitable name for your users. Both can be done using the AWS CDK.<br /> <img loading="lazy" width="1024" height="101" src="https://media.graphassets.com/uYZfnpvoReCMXQIx08bC" alt="configure file" /></p><h2><h2>Tests</h2><p>As you define your infrastructure as code, this code can be tested and validated. You can write simple unit tests using your favorite test suite and scan the generated AWS cloud formation templates. This can be checked against what you expect. As I am using python, there are already testing frameworks available.</p><p>To get a reusable snippet of code, which synthesizes your template, add a fixture:</p>

```
@pytest.fixture()
def template():
    app = core.App()
    NetworkStack(app, "NetworkStackTest")
    return json.dumps(app.synth().get_stack("NetworkStackTest").template)
```

<p>Later this can be used to get a template and check the content using asserts. As an example, you can check that a VPC is defined.</p>

```
def test_vpc_created(template):
    assert("AWS::EC2::VPC" in template)
```

<h2><h2>Conclusion</h2><p>AWS CDK is a very convenient tool for deploying resources to AWS. There are many native AWS mechanisms used so that constructs are easily integrated into existing environments. With a few lines of source code you can define a lot of functionality, as you don’t have to define all resources needed by yourself. The complete code of this blog post is available in the example <a href="https://github.com/dhenne/aws-cdk-fargate-aurora-wordpress-example">Github repository</a> . Give it a try!</p></h2></h2></h2></h2></h2></h2></h2></h2></h2>

Fargate with EFS and Aurora Serverless using AWS CDK

In this post you will learn what GitOps is about and see the steps to create a setup on your laptop to gain some experience with ArgoCD. Using an industry standard container orchestrator such as Kubernetes, this enables developers to continuously deploy their applications.

There is a huge number of options available to deploy artifacts. A widely adopted 
approach uses the <a href='https://github.com/opencontainers/image-spec' target='_blank'>OCI image format</a> to ship your software. A continuous integration pipeline builds the software and creates an artifact. The image can then be deployed by a container orchestrator, i.e. Kubernetes. 

Furthermore, development teams are responsible for the entirety of their applications. Defining the infrastructure and the process as code is crucial
to not reducing efficiency and velocity while keeping all actions reproducible and tackling complexity. Tools such as Terraform and Helm can read a definition and be executed as part of a pipeline to push changes to achieve the desired state.

## The GitOps principles

While traditional pipelines and the tools within such as GitHub Actions or GitLab CI/CD are executed whenever a specific event like a *git push* happens, the GitOps principle works the other way around.
The largest difference is that the desired state is continuously pulled from a source such as a VCS repository to drive the infrastructure. This pattern is called a *reconciliation loop* and matches with the Kubernetes <a href='https://kubernetes.io/docs/concepts/extend-kubernetes/operator/' target='_blank'>operator pattern</a>. 

There are many tools out there that leverage the Kubernetes CRDs as input to define the desired state and apply them by operators.

The elements of GitOps can be described by four principles. 

* Declarative infrastructure
* Desired state is stored versioned and immutable
* Pulled automatically from source code
* Continuously reconciled by software agents

The CNCF hosts the project <a href='https://opengitops.dev/' target='_blank'>OpenGitOps</a> which is an attempt to define an open standard.

## ArgoCD

As stated before, in this blog post we will take a closer look at ArgoCD. This tool focuses on Continuous Delivery of applications to Kubernetes.  

For this purpose, ArgoCD monitors a source and creates the API objects out of its definitions files. A lot of options are available starting from plain YAML files to Helm Charts and Kustomize. Even custom <a href='https://argo-cd.readthedocs.io/en/stable/user-guide/config-management-plugins/' target='_blank'>plugins</a> are possible, which is very handy in migration scenarios or if the need for any custom integrations are a usual pattern in your organization. The core concepts of ArgoCD can be found at <a href='https://argo-cd.readthedocs.io/en/stable/core_concepts' target='_blank'>https://argo-cd.readthedocs.io/en/stable/core_concepts</a>. 

ArgoCD is an excellent fit in our mission to deliver our high-value applications at best-in-class velocity to users.

### Installation

Now it is time to take our first steps into our GitOps journey and try out ArgoCD. First, we need
a Kubernetes cluster to deploy to. I will use Minikube here, but every other distribution will do the job. Simply install <a href='https://minikube.sigs.k8s.io/docs/start/' target='_blank'>Minikube</a> and start your local cluster:

```
minikube start --driver=docker
```

After your kubectl tool is configured and you can access your cluster, clone the demo repository and install ArgoCD.

```
git clone git@github.com:dhenne/minikube-argocd-traefik-example.git
```

There is a `bootstrap-argo-cd` chart in the folder `charts/`, which can be used to bootstrap your ArgoCD installation using the helm CLI tool. Later we will use this instance of ArgoCD to manage itself. 


```
cd minikube-argocd-traefik-example/charts/bootstrap-argo-cd/
helm dependency build
helm install argo-cd .
```


After all images are downloaded and the pods are started, you should see a few pods running:

*kubectl get pods*
```
NAME                                                       READY   STATUS    RESTARTS   AGE
argo-cd-argocd-application-controller-0                    1/1     Running   0          52s
argo-cd-argocd-applicationset-controller-bf44c7bc9-2k4w9   1/1     Running   0          53s
argo-cd-argocd-dex-server-8676995c89-7pb5x                 1/1     Running   0          53s
argo-cd-argocd-notifications-controller-7d9d94f45d-rk5kh   1/1     Running   0          53s
argo-cd-argocd-redis-6749667d89-7prsk                      1/1     Running   0          53s
argo-cd-argocd-repo-server-58b8864fc7-kvtln                1/1     Running   0          53s
argo-cd-argocd-server-78fd54c49d-dvv7d                     1/1     Running   0          53s
```

Nice! To interact with the installation and check out what is going on, we can use the UI. The password can be found inside a secret which is automatically created if not disabled by a configuration parameter. Get yours with `kubectl -n default get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d` forwarding a port to your workspace using the command `kubectl port-forward service/argo-cd-argocd-server -n default 8080:443 &` and browse to http://localhost:8080.

After login with the user `admin` you can see there are no applications deployed yet.

![no-applications-yet.png](https://media.graphassets.com/qRtVD5jDTyXSKRcVe8gF)

Congratulations, now we can start delivering!

### Apps-of-apps pattern

ArgoCD introduces an <a href='https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/#app-of-apps-pattern' target='_blank'>app-of-apps pattern</a>. As applications can be defined in CRDs, applications can be part of an application. This can be used as a starting point to define which applications have to be deployed.

To demonstrate this, there is a root application defined inside the example repository. The definition contains the path pointing to the demo repository:

*charts/root/templates/root.yaml*
```
...
  source:
    repoURL: https://github.com/dhenne/minikube-argocd-traefik-example.git
    path: charts/root
    targetRevision: HEAD
...
```

The root application of the demo project includes another definition for ArgoCD. Unlike before, the source is a Helm repository. This definition causes ArgoCD to match the previously installed instance and therefore to manage itself. Now you are enabled to get <a href='https://docs.renovatebot.com/modules/manager/argocd/' target='_blank'>automated updates using Renovate</a> to update your installation!  

*<a href='https://github.com/dhenne/minikube-argocd-traefik-example/blob/main/charts/root/templates/argo-cd.yaml' target='_blank'>charts/root/tempaltes/argo-cd.yaml</a>*
```
...
  source:
    repoURL: https://argoproj.github.io/argo-helm
    chart: argo-cd
    targetRevision: 5.4.3
...
```

Use *kubectl apply* to instruct pulling the state from GitHub and apply the defined state:

```
kubectl apply -f charts/root/templates/root.yaml
```

Now watch the state changing until there are some apps including Root and ArgoCD: 

![root-and-argocd.png](https://media.graphassets.com/IfjtNg9SyeUNvY4jweIw)

NOTE: To keep your namespace clean, unlink the ArgoCD instance from your local Helm CLI: `kubectl delete secret -l owner=helm,name=argo-cd` 

Now you can explore the great UI from ArgoCD. Everything is clean and focused on purpose. As mentioned in the core concepts before, there are buttons labeled *refresh* and *sync*. Refreshing causes to poll the source repositories and their state. After that, a sync applies the changes needed to ensure the defined state is in place. If auto sync is enabled, then a sync is done immediately after a refresh causing an out-of-sync state. 

Another very helpful use case is to explore your deployment and get an idea of all parts and their state. If we drill down the `argo-cd` app, there are a lot of resources deployed. It's a lot of work to get an idea of all parts. But within the ArgoCD UI, everything is well organized and it's easy to check out all parts in detail. In fact, there are 47 resources. All relations definitions states, logs, and events are a few clicks away. Even parts that are paid less attention to such as replica sets or endpoints fit nicely into the big picture.

## Application gitopsified

![gitopsify-all-the-things.jpg](https://media.graphassets.com/a2QZLvT8RrqBpVWl0uTx)

It's time for additional proof of the ability to deploy our apps. The <a href='https://github.com/dhenne/minikube-argocd-traefik-example/' target='_blank'>demo repository</a> mentioned before can be seen as a widely used pattern of a GitOps repository. There you can find definitions of the desired state, but the source code can be found in a separate repository. In this article, I will demonstrate a slightly different approach. We only define which applications will be deployed and the desired state is placed in your application's source code repositories. Developers then have to do all their changes inside one repository, without the need to keep an eye on the GitOps repository. Of course, you can achieve that using custom pipelines and other tools, but we want a GitOps-style approach here that polls information instead of pushing it to the GitOps repo. On top of that, ArgoCD is our tool of choice here, and it can achieve that. Why should we bother with custom self-made approaches? Be aware that configuration in source code repositories can be considered a violation of <a href='https://argo-cd.readthedocs.io/en/stable/user-guide/best_practices/#best-practices' target='_blank'>best practices</a>, so prepare yourself for a good discussion (maybe with this article). 

While there's a <a href='https://github.com/argoproj/argo-cd/blob/master/docs/proposals/multiple-sources-for-applications.md' target=_blank>proposal</a>, which aims at first-class support of multiple sources for our definitions, we have to use ArgoCD <a href='https://argocd-applicationset.readthedocs.io/en/stable/Generators/' target='_blank'>generators</a> to use multiple sources to define our state. Generators are included within the ApplicationsSet feature, which has been fully <a href='https://github.com/argoproj/applicationset/releases/tag/v0.4.0' target=''>integrated into the ArgoCD installation</a> since 2022. ApplicationSets are a great option to template your application definitions without Helm or anything else. Therefore, using the <a href='https://argocd-applicationset.readthedocs.io/en/stable/Generators-Git/' target='_blank'>Git Generator</a> can be considered as a first-class approach, too.

There are two options available for the Git Generator. While the *directories* key scans a directory and creates an application for every folder found, the *files* key does the same thing for a file-matching pattern.

![argo-multisource.png](https://media.graphassets.com/hx4GsjLORIqFkKBTxXAU)

The demo repository contains another application in the root app named `spring-boot-apps`, which references a Helm Chart consisting of ApplicationSet definitions to demonstrate the two options. Exploring them in the UI can be done in the root app using a link in the application representation. This shortcut is quite handy to move around while using the app-of-apps pattern.

![link-app-of-apps.png](https://media.graphassets.com/4pGAq7Qxq7N8Yf8uIsdw)

Following the link, you can see two ApplicationSets, which consist of two applications each for a test and production stage. Let's have a look at both sets.


![spring-boot-apps.png](https://media.graphassets.com/8YDMaHsMQemUTUrMieyT)


### Git Generator: Directories

In my opinion, the Directories Generator is the best approach. It generates applications from a pattern that matches folders. Inside the folders, everything that is <a href='https://argo-cd.readthedocs.io/en/stable/user-guide/application_sources/' target='_blank'>supported</a> can be placed. This provides superior flexibility for developers, which encourages people to strive towards a DevOps culture. In the demo repository, you'll find Helm Charts, but it doesn't matter for the application definition and can be swapped to other options in different stages without redefining the ApplicationSet itself. Another advantage worth mentioning is the avoidance of ArgoCD or organization-specific schema of your definitions inside the source code repository. Developers can use their knowledge of existing standards. Below you can find the definition which points to a Spring Boot application.

<a href='https://github.com/dhenne/minikube-argocd-traefik-example/blob/main/charts/spring-boot-apps/templates/springboot-appset-git-directories.yaml' target='_blank'>charts/spring-boot-apps/templates/springboot-appset-git-directories.yaml</a>

```
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: springboot-appset-git-directories
spec:
  generators:
    - git:
        repoURL: https://github.com/dhenne/spring-boot-service
        revision: HEAD
        directories:
          - path: "deployment/helm/*"
  template:
    metadata:
      name: '{{`{{path.basename}}`}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/dhenne/spring-boot-service
        path: '{{`{{path}}`}}'
        targetRevision: HEAD
      destination:
        server: https://kubernetes.default.svc
        namespace: default
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
```

NOTE: Unlike the files generator, using paths inside hidden folders is not supported, as the folders are <a href='https://github.com/argoproj/argo-cd/blob/02bf903dd9b25c141d073bab3c7588d190145eb3/applicationset/services/repo_service.go#L109' target='_blank'>skipped</a>. 

### Git Generator: Files

Another generator that can be used is the Files Generator that looks for files matching the provided pattern. Each file can then define keys and values in JSON or YAML format. When ArgoCD is generating the applications, values can be used in a template spec to define applications. Think of Helm Charts, then you got the concept. In the demo repository, we use Helm Charts, so we have to exclude ArgoCD templating from the Helm templating engine using Go strings. 

<a href='https://github.com/dhenne/minikube-argocd-traefik-example/blob/main/charts/spring-boot-apps/templates/springboot-appset-git-files.yaml' target='_blank'>charts/spring-boot-apps/templates/springboot-appset-git-files.yaml</a>
```
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: springboot-appset-git-files
spec:
  generators:
    - git:
        repoURL: https://github.com/dhenne/spring-boot-service
        revision: HEAD
        files:
          - path: "deployment/multisource-files/**.yaml"
  template:
    metadata:
      name: '{{`{{name}}`}}'
    spec:
      project: default
      source:
        repoURL: https://dhenne.github.io/helm-charts/
        chart: spring-boot-helm-demo
        targetRevision: 0.1.6
        helm:
          values: |-
            {{`{{values}}`}}
      destination:
        server: https://kubernetes.default.svc
        namespace: default
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
```

## Developer Workflow

The workflow for developers to deploy new versions consists of a single commit to the application repository. To instruct ArgoCD to deploy a new version, developers only need to adjust the version number inside the configuration file of the correct environment. For example, the test environment of the directories example can be found in the <a href="https://github.com/dhenne/spring-boot-service/blob/main/deployment/helm/springboot-helm-test/values.yaml" target="_blank">values.yaml</a> in the application repository. There is a GitHub workflow to demonstrate an automated version bump, release, and deployment of the <a href="https://github.com/dhenne/spring-boot-service/" target="_blank">spring-boot-service</a> to test environments. The production environments are requiring manual confirmation to allow the workflow to proceed. All information defining the application and the corresponding environments can be found in one place, which is a big advantage of this approach.

## Conclusion

ArgoCD <a href='https://argo-cd.readthedocs.io/en/stable/#why-argo-cd' target='_blank'>promises</a> to provide an easy-to-understand GitOps tool. As we have seen, this is perfectly true. There is a lot of flexibility while keeping things aligned on purpose. The UI is very helpful to drill down into the complexity of large deployments and developers can still use their favorite standard tooling for defining applications in Kubernetes. If you consider digging deeper into the topic, the <a href='https://github.com/terrytangyuan/awesome-argo' target='_blank'>awesome-argo</a> list might be a good start.

Argonauts, to the moon!

### Links

<a href='https://github.com/argoproj/argo-cd' target='_blank'>https://github.com/argoproj/argo-cd</a>

<a href='https://github.com/dhenne/minikube-argocd-traefik-example' target='_target'>https://github.com/dhenne/minikube-argocd-traefik-example</a>





Introduction to GitOps with ArgoCD

Senior IT Consultant & Developer

<div><div><p>Mit Kotlin Multiplatform Mobile (KMM) steht ein weiteres Cross-Platform Framework in den Startlöchern. Diesmal geht JetBrains ins Rennen und versucht natürlich alles besser zu machen als alle anderen. Die Frage ist aber: Brauchen wir das wirklich? Ist es einfach nur eine weitere Kopie in neuem Gewand?<br /> Um das herauszufinden, habe ich eine kleine App gebaut und wir schauen uns gemeinsam an, wie das Ganze funktioniert. <a href="https://github.com/darthkali/kmmbikeshare" target="_blank">Hier findet ihr</a>  die Beispiel-App, auf die ich mich im Beitrag beziehe.</p><div><h2><strong>Grundlegender Aufbau von Kotlin Multiplatform Mobile</strong></h2><div><div><p>Starten wir zunächst mit dem Aufbau einer Kotlin Multiplatform Mobile-App. Ein KMM-Projekt basiert in erster Linie auf Modularisierung. Folgt man dem Standardweg von Kotlin, erhält man folgende Struktur:</p></div><div><div><img src="https://media.graphassets.com/wZx4FYH6TZikCTxgemlf" alt="Bild zeigt wie die Struktur einer KMM App ist." /></div></div><div><p>Wir haben also ein Android-Modul, ein iOS-Modul und ein shared-Modul. In den Android- bzw. IOS-User-Interface-Modulen implementieren wir hauptsächlich Elemente für das User Interface, während wir die Business- und Datenlogik im shared-Modul umsetzen. Eine strikte Regel für die Abgrenzung gibt es jedoch nicht. Erscheint es für den Anwendungsfall sinnvoll, einen Teil der Businesslogik in die UI-Module zu ziehen, ist das mit Kotlin Multiplatform Mobile ohne Weiteres möglich. Die Implementierungen werden dann nicht zwischen den Systemen geteilt. Diese Flexibilität ist ein großer Vorteil von Kotlin Multiplatform Mobile.</p></div><div><p>Innerhalb des shared-Moduls erfolgt eine Aufteilung in common, iOS und Android Packages. Der größte Teil der Entwicklung findet im common Package statt. Hier liegt in der Regel die komplette Implementierung der Business- und Datenlogik. Also alles von der Implementierung der Datenbank, über die Remoteschnittstelle, bis hin zur Domänenlogik. In die beiden systemspezifischen Packages innerhalb des shared-Moduls kommen nur die Implementierungen, die wir für die jeweiligen Systeme separat entwickeln müssen. Das sind meist nur Treiberimplementierungen oder Ähnliches.</p></div><div><p>Neben den oben genannten Modulen gibt es dann auch das passende Pendant für die Tests. Auch hier erfolgt der Hauptteil im CommonTest Package während wir in den systemspezifischen Packages nur das Setup und die Treiber implementieren.</p></div><div><p>Damit wissen wir nun, wie der ganz grobe Aufbau der App ist. Wie das Ganze im Detail funktioniert, schauen wir uns in den kommenden Abschnitten an.</p></div></div></div><div><h2><strong>expect / actual – was ist das?</strong></h2><div><div><p>Bevor wir uns auf konkrete Implementierungen stürzen, müssen wir vorher noch eine wichtige Funktionalität betrachten. Ich habe im letzten Abschnitt erwähnt, dass wir für manche Anwendungsfälle separate Implementierungen benötigen. Wir brauchen also einen Mechanismus, der eine Weiche darstellt, um jeweils die spezifische Implementierung für die passende Plattform zu kompilieren.<br /> Hierzu kommt das Feature <em>expect / actual</em> zum Einsatz.</p></div><div><div>expect / actual</div><div>

```rouge highlight
// Common
expect fun sharedFunction(parameter: String): String


// iOS
actual fun sharedFunction(parameter: String): String {
    return “this is the iOS implementation”
}


// Android
actual fun sharedFunction(parameter: String): String {
    return “this is the Android implementation”
}
```

</div></div><div><p>Im common Package definieren wir, was implementiert werden soll, ohne jedoch eine direkte Implementierung an dieser Stelle zu erstellen. Das Keyword <em>expect</em> sorgt dafür, dass der Compiler eine Implementierung erwartet. Sie muss den gleichen Namen aufweisen und den gleichen Package-Pfad besitzen. Danach können wir die Methode oder Klasse in dem jeweiligen plattformspezifischen Package implementieren.</p></div></div></div><div><h2><strong>Codesharing zwischen iOS und Android</strong></h2><div><div><p>Kommen wir mal zu den harten Fakten. Was lässt sich denn jetzt wirklich alles teilen? Wie viel müssen wir ggf. doch parallel implementieren?</p></div><div><h3><strong>User Interface</strong></h3><div><p>Wie schon etwas weiter oben beschrieben sind wir absolut frei, was wir teilen wollen. Ob wir nur eine einzige Methode teilen oder die kompletten Daten und Domänenlogik ist uns komplett frei gestellt. Was wir jedoch nicht teilen sollten, ist das User Interface und seine Komponenten. Demzufolge müssen wir auch die UI-Tests jeweils plattformspezifisch entwickeln, was durchaus Sinn ergibt.</p></div></div><div><h3><strong>UI-State</strong></h3><div><p>Da der State in der Beispielanwendung lediglich eine Dataclass ist, kann man ihn durchaus teilen. Aber auch hier merkt man schon, dass wir für die jeweilige Plattform kleine Abweichungen einbauen müssen. Für iOS benötigen wir einen eigenen Konstruktor. So muss man es zwar dennoch doppelt schreiben, hat es aber zumindest in einer Datei, was sicherlich Geschmackssache ist.</p></div><div><div>UI-State</div><div>

```rouge highlight
data class BicycleSharingSystemListState(
    val isLoading: Boolean = false,
    val country: String = "",
    val bicycleSharingSystems: List<BicycleSharingSystem> = listOf(),
) {
    // Need secondary constructor to initialize with no args in SwiftUI
    constructor() : this(
        isLoading = false,
        country = "",
        bicycleSharingSystems = listOf(),
    )
}
```

</div></div></div><div><h3><strong>Remote-Zugriff</strong></h3><div><p>Für die Umsetzung der Remote-Schnittstelle haben wir Ktor als Framework verwendet, was auch JetBrains offiziell als Lösung vorgeschlägt.</p></div><div><p>Hierfür benötigen wir für iOS und Android zunächst eine separate Implementierung des Treibers. Es existieren also in der <em>commonMain</em> eine <em>KtorClientFactory</em>-Klasse, die wir als <em>expect</em> deklarieren, sowie jeweils eine <em>actual</em>-Klasse für Android und iOS. Deren Implementierungen sehen dann wie folgt aus:</p></div><div><div>KtorClientFactory</div><div>

```rouge highlight
expect class KtorClientFactory() {
    fun build(): HttpClient
}


iOS
actual class KtorClientFactory {
    actual fun build(): HttpClient {
        return HttpClient(Ios) {
            install(JsonFeature) {
                serializer = KotlinxSerializer(
                    kotlinx.serialization.json.Json {
                        ignoreUnknownKeys = true
                        useAlternativeNames = false

Android
actual class KtorClientFactory {
    actual fun build(): HttpClient {
        return HttpClient(Android) {
            install(JsonFeature) {
                serializer = KotlinxSerializer(
                    kotlinx.serialization.json.Json {
                        ignoreUnknownKeys = true
```

</div></div><div><p>Hier ist zu erkennen, dass die Implementierungen jeweils recht ähnlich sind. Der wichtigste Unterschied ist, dass bei der jeweiligen Plattform die passende Client-Engine (iOS respektive Android) an den <em>HttpClient</em> übergeben wird. Zur Serialisierung der Klassen nutzt KMM in beiden Fällen die KotlinX Serialization.</p></div><div><p>Mit der Implementierung der <em>KtorClientFactory</em> ist die Grundlage für die Remote-Anbindung bereits eingearbeitet. Das ist gleichzeitig die einzige Stelle, an der wir zwischen iOS und Android unterscheiden müssen. Die restliche Implementierung erfolgt wieder als komplett geteilte Codebasis.</p></div></div><div><h3><strong>Asynchronität</strong></h3><div><p>Neben vielen Klassen und Methoden, die problemlos zwischen iOS und Android teilbar sind, gibt es auch solche, bei denen das nicht ohne Weiteres machbar ist. Ein Beispiel ist die Verwendung von Coroutines. Um Asynchronität zu implementieren, bietet Kotlin für Android die <em>kotlinx.coroutines</em>-Bibliothek an. Das ist unter anderem für die Implementierung der Remote-Anbindung nötig. iOS kann diese Funktionalität jedoch nicht nutzen.</p></div><div><p>Zur Lösung dieses Problems gibt es verschiedene Ansätze:</p></div><div><h4><strong>KMP Beta</strong></h4><div><p>Zum einen kann man ganz entspannt einen Kaffee trinken und warten, bis KMM <a href="https://blog.jetbrains.com/kotlin/2021/08/try-the-new-kotlin-native-memory-manager-development-preview/" target="_blank">in die Beta kommt</a> . Hier wird laut JetBrains ein neuer Kotlin/Native-Memory-Manager zum Einsatz kommen. Damit sollen die Differenzen zwischen den beiden System begradigt werden und das Arbeiten mit Asynchronität deutlich vereinfacht werden.</p></div></div><div><h4><strong>FlowHelper</strong></h4><div><p>Wer nicht warten kann, hat auch jetzt schon Möglichkeiten. In unserer Beispiel-App haben wir das ganze mit einem Wrapper gelöst. Der FlowHelper kann unterscheiden, ob es eine iOS-App oder eine Android-App ist.</p></div><div><div>Flow Helper</div><div>

```rouge highlight
fun <T> Flow<T>.asCommonFlow(): CommonFlow<T> = CommonFlow(this)

class CommonFlow<T>(private val origin: Flow<T>) : Flow<T> by origin {
    fun collectCommon(
        coroutineScope: CoroutineScope? = null, // 'viewModelScope' on Android and 'nil' on iOS
        callback: (T) -> Unit, // callback on each emission
    ) {
        onEach {
            callback(it)
        }.launchIn(coroutineScope ?: CoroutineScope(Dispatchers.Main))
    }
}
```

</div></div><div><p>Für Android gibt man dem FlowHelper einfach den <em>Coroutinescope</em> mit und setzt den Callback auf <em>null</em>. Der Rest funktioniert dann wie gewohnt mit der <em>coroutinex.flow dependency</em>.</p></div><div><div>collectCommon Implementierung Android</div><div>

```rouge highlight
searchBicycleSharingSystems.execute(
    country = state.value.country,
).collectCommon(viewModelScope) { dataState ->
    state.value = state.value.copy(isLoading = dataState.isLoading)

    dataState.data?.let { bicycleSharingSystems ->
        appendBicycleSharingSystem(bicycleSharingSystems)
        saveAllBicycleSharingSystems(bicycleSharingSystems)
    }
}
```

</div></div><div><p>Bei iOS gibt man einen Callback mit. Man implementiert hier eine Funktion, die KMM dann anstelle der Couroutines ausführt.</p></div><div><div>collectCommon Implementierung iOS</div><div>

```rouge highlight
searchBicycleSharingSystems.execute(
    country: currentState.country
).collectCommon(
    coroutineScope: nil,
    callback: {
        >>> Here you can write your code
    })
```

</div></div></div></div><div><h3><strong>Datenbankzugriff</strong></h3><div><p>Für die Datenbankanbindung haben wir SQLDelight genommen. Das war zum Zeitpunkt der Erstellung das einzige Framework, das sowohl für Android wie auch für iOS eine Implementierung zur Verfügung stellte. Neben SQL Delight gibt es inzwischen auch die Möglichkeit, Realm als Datenbank zu nutzen.</p></div><div><h4><strong>Grundlegende Implementierung</strong></h4><div><p>Ähnlich der Remote-Schnittstelle mit Ktor bedarf es hier ebenfalls einer plattformspezifischen Implementierung der Treiber. Das haben wir ähnlich der Implementierung der PeopleInSpace App von John O’Reilly umgesetzt.</p></div><div><div>Platform Module für die Datenbank</div><div>

```rouge highlight
expect fun platformModule(): Module
```

</div></div><div><p>In den jeweiligen plattformspezifischen Modulen wird der passende Treiber genutzt und das Datenbankschema wie auch der Datenbankname übergeben.</p></div><div><div>Platform Module für die Datenbank – iOS</div><div>

```rouge highlight
actual fun platformModule() = module {
    single {
        val driver = NativeSqliteDriver(KmmBikeShareDatabase.Schema, "BikeShareDb.db")
        KmmBikeShareDatabaseWrapper(KmmBikeShareDatabase(driver))
    }
}
```

</div></div><div><div>Platform Module für die Datenbank – Android</div><div>

```rouge highlight
actual fun platformModule() = module {
    single {
        val driver =
            AndroidSqliteDriver(KmmBikeShareDatabase.Schema, get(), "BikeShareDb.db")
        KmmBikeShareDatabaseWrapper(KmmBikeShareDatabase(driver))
    }
}
```

</div></div><div><p>Das Datenbankschema wird zunächst in SQLDelight-Dateien definiert. Hier wird klassisch erst die Tabelle mit den Attributen und deren Eigenschaften definiert. Danach erfolgen die konkreten Datenbankabfragen (CRUD-Methoden), die später für die App zum Einsatz kommen. Innerhalb der <em>build.gradle.kts</em> wird die SQLDelight-Erweiterung definiert und sowohl der Datenbankname, als auch das Verzeichnis zu den oben beschriebenen Datenbankschemata hinterlegt. Um das anschließend nutzen zu können, müssen wir diesen Abschnitt zunächst kompilieren. Erfolgt eine Änderung an dem Schema, muss ein Rebuild erfolgen, damit die Änderungen wirksam werden.</p></div><div><p>SQLDelight erzeugt aus den Dateien einige neue Dateien, darunter die Implementierung der Datenbank, die die notwendigen Methoden und Verknüpfungen für die Entitäten und die Queries enthält. Außerdem sind hier weitere grundlegende Methoden inbegriffen, zum Beispiel <em>getLastInsertRowId</em>, die die zuletzt eingefügte ID zurückgibt. Das ist später sehr nützlich, um bei einem <em>Insert</em>-Befehl die ID zurückzugeben, um damit weiterzuarbeiten.</p></div><div><p>Die eigentliche Implementierung besteht aus dem Mapper, dem Datenbankmodell und den jeweiligen Repositories.</p></div></div></div><div><h3><strong>Test</strong></h3><div><p>Ein großer Vorteil der geteilten Codebasis ist, dass die Tests ebenfalls geteilt werden können.</p></div><div><p>In der App haben wir Tests für die lokalen Datenbankimplementierungen und für die Interactors erstellt. In diesem Abschnitt geht es also nur um die Tests, die sich innerhalb der geteilten Codebasis befinden.</p></div><div><p>Als Grundlage für die Tests haben wir den <em>BaseTest</em> eingebaut. Er ist im commonMain Package ebenfalls als <em>expect</em> deklariert, da es hier nötig ist, eine Unterscheidung zwischen Android und iOS zu treffen. Der <em>BaseTest</em> ist grundlegend so aufgebaut, dass es möglich ist, darin eine Suspend Function aufzurufen. Dazu muss er in einem <em>CoroutineScope</em> laufen. Außerdem müssen die Module für die Dependency Injection angelegt werden. Diese beiden Aufgaben sorgen dafür, dass die Basisklasse separat für Android und iOS gehandhabt werden muss. Eine weitere wichtige Aufgabe in Bezug auf Koin und den <em>CoroutineScope</em> ist es, diese zu starten und vor allem auch wieder zu stoppen.</p></div><div><div>BaseTest expect im Common Main</div><div>

```rouge highlight
expect abstract class BaseTest() : KoinTest {
    fun <T> runTest(block: suspend CoroutineScope.() -> T)
}
```

</div></div><div><h4><strong>Android</strong></h4><div><p>Unter Android gestaltet sich das unkompliziert. Hier können wir eine <em>KoinTestRule</em> erzeugen, die eine <em>ﬁnished</em>– und eine <em>starting</em>-Methode beinhaltet, die KMM dann automatisch ausführt. Der Coroutine Scope wird ebenfalls selbstständig gestartet und anschließend auch wieder beendet.</p></div><div><div>BaseTest unter Android</div><div>

```rouge highlight
@RunWith(AndroidJUnit4::class)
actual abstract class BaseTest : KoinTest {
    @get:Rule
    val koinTestRule = KoinTestRule.create {
        androidContext(ApplicationProvider.getApplicationContext())
        modules(
            network,
            ...
        )
    }
    actual fun <T> runTest(
        block: suspend CoroutineScope.() -> T
    ) { runBlocking { block(
}
```

</div></div></div><div><h4><strong>iOS</strong></h4><div><p>Für iOS müssen wir die gleiche Funktionalität erzeugen. Aktuell gib es hierfür noch keine spezielle Bibliothek, die das gewährleistet. Um die Funktionalität dennoch zu erzeugen, wurde eine Implementierung benutzt, die aus dem <em>touchlab/KaMPkit</em>-Repository stammt.</p></div><div><p>Für iOS wird der Dispatcher händisch in die <em>BaseTest</em>-Klasse eingebracht und erzeugt ebenfalls eine Methode, mit der die Tests ausführbar sind. Auch hier ist zu sehen, dass Koin zunächst gestartet wurde und später wieder beendet wird. Ebenfalls wird ein <em>CFRunLoop</em> gestartet, der eine Basisimplementierung unter iOS ist. Dieser wird zum Ende hin ebenfalls beendet.</p></div><div><div>BaseTest unter iOS</div><div>

```rouge highlight
actual abstract class BaseTest : KoinTest {

    @OptIn(DelicateCoroutinesApi::class)
    actual fun <T> runTest(block: suspend CoroutineScope.() -> T) {
        var error: Throwable? = null

        GlobalScope.launch(Dispatchers.Main) {
            try {
                initKoin()
                block()
            } catch (t: Throwable) {
                error = t
            } finally {
                stopKoin()
                CFRunLoopStop(CFRunLoopGetCurrent())
            }
        }
        CFRunLoopRun()
        error?.also { throw it }
    }
}
```

</div></div><div><p>Die Testklassen erben nun vom <em>BaseTest</em>. Innerhalb der Testklasse erzeugen wir zunächst eine Methode, die vor jedem Test läuft und einen Basissatz an Daten in der Datenbank implementiert. Sie ist mit <em>@BeforeTest</em> annotiert und nutzt die <em>runTest</em>-Methode aus dem <em>BaseTest</em>.</p></div><div><p>An den Tests wird nun noch die Annotation <em>@Test</em> notiert. Ebenso wird hier die <em>runTest</em>-Methode aus der <em>BaseTest</em>-Klasse wieder verwendet. Die Daten, die die <em>Setup</em>-Methode erzeugt, stehen anschließend vor jedem der Tests zur Verfügung. Die restliche Testimplementierung erfolgt wiederum nach dem Aufbau, wie er von der klassischen Android-Entwicklung bekannt ist.</p></div></div></div></div></div><div><h2><strong>Conclusion</strong></h2><div><div><p>Damit sind die wichtigsten Aspekte von Kotlin Multiplatform Mobile aufgezeigt. Wenn wir einmal auf die Ausgangsfrage zurückkommen, ob JetBrains nur eine weitere Kopie eines bestehenden Crossplatform Frameworks gebaut hat, kann man das ganz klar verneinen.<br /> KMM verfolgt einen deutlich anderen und vor allem freieren Weg, der auch jetzt schon viel Anklang in der Welt der Mobile-App-Entwicklung erhält.<br /> Es gibt bereits jetzt für alle wichtigen Teilbereiche, die in der App-Entwicklung nötig sind, einsatzbereite Frameworks. Wir können von der Businesslogik, über die Remoteanbindung bis zu den Tests alles teilen.</p></div><div><p>Dennoch gibt es auch Hürden, die man nehmen muss. Die Ersteinrichtung vor allem auf iOS-Seite ist mitunter schwierig. Auch sind die externen Bibliotheken mitunter noch nicht für KMM ausgelegt. Und auch die kleinen Schwierigkeiten mit dem Memory-Modell lassen noch Raum für Verbesserung.</p></div><div><p>Alles in allem sollte man dieses Framework nicht aus dem Blick verlieren. Für den entsprechenden Use Case kann und wird sich KMM durchaus relevant einsetzen lassen.</p></div></div></div></div></div>

Kotlin Multiplatform Mobile – Ein praktischer Einstieg

Vor drei Monaten konnte ich zum ersten Mal mit GitHub Copilot von Microsoft auf die Startbahn gehen. Ob der Flug erfolgreich war oder ob ich es gar nicht in die Luft geschafft habe, möchte ich euch einmal berichten.

## Was ist GitHub Copilot?
Der Copilot ist ein intelligenter Assistent, der euch beim Programmieren helfen soll. Dies erfolgt in der Form von Vorschlägen, die euch Copilot in Echtzeit während der Eingabe anzeigt.
Beim Copilot handelt es sich um eine Künstliche Intelligenz, die auf <a href="https://openai.com/blog/openai-codex/" target="_blank">OpenAI Codex </a> basiert. 


## Registrieren und Installieren  
Zunächst werfen wir einen Blick in den Registrierungs- und Installationsprozess. Als Erstes müsst ihr euch bei GitHub registrieren und dort eine Lizenz erwerben. Der Copilot ist leider nicht kostenlos. Es besteht aber die Möglichkeit das Tool zunächst 60 Tage lang zu testen. Danach kostet es 10 $ pro Monat oder 100 $ pro Jahr. 

Studierende haben die Möglichkeit, sich über die <a href="https://education.github.com/" target="_blank">GitHub-Education-Seite</a> zu registrieren und sich den GitHub-Pro-Account zu sichern. Darin sind einige Tools enthalten. Unter anderem <a href="https://docs.github.com/en/copilot/overview-of-github-copilot/about-github-copilot#about-billing-for-github-copilot" target="_blank">GitHub Copilot</a>, aber auch der Azure-Edu-Account mit 100 $ Startbonus (kann man sich durchaus mal anschauen). 

Nach der Registrierung müsst Ihr Copilot in eurer IDE als Plugin installieren.
Ich habe das ganze ausschließlich in IntelliJ und Android Studio genutzt, weshalb hier nur dieser Weg aufgezeigt wird. Neben den <a href="https://docs.github.com/en/copilot/getting-started-with-github-copilot/getting-started-with-github-copilot-in-a-jetbrains-ide" target="_blank">JetBrain IDEs </a>     steht euch Copilot auch noch in
<a href="https://docs.github.com/en/copilot/getting-started-with-github-copilot/getting-started-with-github-copilot-in-visual-studio-code" target="_blank">Visual Studio Code</a>, <a href="https://docs.github.com/en/copilot/getting-started-with-github-copilot/getting-started-with-github-copilot-in-visual-studio" target="_blank">Visual Studio</a> und <a href="https://docs.github.com/en/copilot/getting-started-with-github-copilot/getting-started-with-github-copilot-in-neovim" target="_blank">Neovim</a> zur Verfügung.


GitHub stellt Copilot als Plugin bereit und ihr könnt ihn mit wenigen Klicks innerhalb der IDE im Pluginfenster installieren. 

![](https://media.graphassets.com/yndDfMvaT5GtXHbwo03Q)

Ist das abgeschlossen, müsst ihr noch euren GitHub-Account mit der IDE verbinden! Hierdurch wird geprüft, ob ihr eine gültige Lizenz besitzt. Das Login-Fenster findet ihr (in IntelliJ) ganz unten rechts in der Taskbar. 

<img src="https://media.graphassets.com/4csRilxRauicu6YEEO55" width="200" />

Danach könnt ihr direkt mit Programmieren anfangen und Copilot wird euch ab sofort Vorschläge geben.


## Wie funktioniert es in der IDE?

Nachdem Copilot eingerichtet ist, könnt Ihr mit der Benutzung starten. Der zunächst intuitive Anwendungsfall ist die Inline-Vervollständigung. Ihr habt eine bereits implementierte Funktion und wollt diese nun im Code aufrufen. Fangt ihr an, diese Funktion einzutippen, erscheint ein ausgegrauter Vorschlag. Das Besondere dabei ist, dass auch die Übergabeparameter mit syntaktisch korrekten Parametern vorgeschlagen werden.

**Du tippst:**
``` Kotlin
sumOf
```

**Vorschlag vom Copilot:**
``` Kotlin
sumOfTwoNumbers(2, 5)
```

Gefällt euch der Vorschlag nicht, habt ihr drei Möglichkeiten, damit umzugehen. 
Zum einen könnt Ihr mit der Tastenkombination `Option + [` bzw. `Option + ]` durch weitere Vorschläge iterieren. Natürlich nur sofern diese vorhanden sind. Zum anderen könnt Ihr den Vorschlag mit `Esc` ablehnen. 

Das Schönste an Copilot ist aber die Möglichkeit, weiterzuschreiben und ihn einfach zu ignorieren. Im Gegensatz zu anderen solcher Tools stört er fast nie. Warum fast nie? Weil es hin und wieder vorkommt, dass er mehrere Zeilen an Vorschlägen macht und sich somit der eigentliche Code nach unten bewegt. Will man aktuell gar nicht mit ihm arbeiten, glitscht es dann ein wenig. Aber das ist selten und stört in Summe nicht. 
Wollt ihr dennoch mal Ruhe von Copilot haben, könnt ihr ihn mit zwei Klicks leicht deaktivieren. Entweder komplett oder für einen bestimmen Dateityp. Das findet ihr am gleichen Ort wie für die Authentifizierung mit GitHub (in IntelliJ).

<img src="https://media.graphassets.com/8SawieNyROinyPIZE1Mn" width="200"/>


**Hier noch einmal die Shortcuts in der Zusammenfassung:**

| Aktion                | Windows / Linux | macOS       |
| --------------------- | --------------- | ----------- |
| Inline-Vorschläge     | Alt + \         | Option + \  |
| nächster Vorschlag    | Alt + ]         | Option + ]  |
| vorheriger Vorschlag  | Alt + \[        | Option + \[ |
| Vorschlag akzeptieren | Tab             | Tab         |
| Vorschlag ablehnen    | Esc             | Esc         |
 *In anderen IDEs können die Shortcuts abweichen


### Beispiele
Besonders positiv ist mir Copilot bei der Verwendung von Methoden mit vielen Parametern aufgefallen. Gerade beim Nutzen von Datenklassen, die dann in Mocks genutzt wurden, musste ich mir keine Dummy-Daten ausdenken – zum Beispiel beim Verwenden eines Personenobjekts.

``` Kotlin
data class Person(  
	val name: String,  
	val age: Int,  
	val isMarried: Boolean,  
	val children: List<Person>  
)
```
Jetzt gibt man nur  `Person` ein und Copilot schlägt dann etwas wie das folgende vor:
``` Kotlin
Person(  
	name = "John", age = 30, isMarried = true, children = listOf(  
		Person(  
			name = "Mary", age = 15, isMarried = false, children = listOf()  
		),   
		Person(  
			name = "Bob", age = 20, isMarried = false, children = listOf()  
		)  
	)  
)
```
Ok zugegeben, dass John mit 10 Jahren schon den Bob als Kind bekam, scheint nicht ganz realistisch. Hieran erkennt man aber auch die Grenze der KI.

Eine weitere Möglichkeit zur Generierung von Code ist das Schreiben von Kommentaren. Ihr könnt einfach beschreiben, was ihr haben möchtet und Copilot liefert euch einen oft ganz guten Ansatz. 

**Beispiel:**
``` Kotlin
// write a function, that can calculate the sum of 2 float values
```

**Copilot schlägt dann folgendes vor:**
``` Kotlin
fun sum(a: Float, b: Float): Float {  
	return a + b  
}
```

Ihr könnt auch auf anderen Sprachen als Englisch schreiben. Hier zum Beispiel mal zum Vergleich auf Englisch und Deutsch.
``` Kotlin
class Test(){  
//write a function, that takes a string and returns the first character of the string  
//if the string is empty, return null    

fun firstChar(str: String): Char? {  
    if (str.isEmpty()) {  
        return null  
    }  
    return str[0]  
}  
```
  
``` Kotlin
// schreibe eine Funktion, die einen string übergeben bekommt und den ersten Buchstaben des Strings zurückgibt  
// wenn der String leer ist, gib 5 zurück    

fun firstChar2(str: String): Char? {  
	if (str.isEmpty()) {  
		return '5'  
	}  
	return str[0]  
}  
```
*Den Return habe ich geändert, damit man erkennt, dass es unterschiedliche Vorschläge sind.

Copilot kann durchaus noch mehr. Hier sind vor allem auch kreative Ideen gefragt. Eine kleine Auflistung liefert GitHub im Artikel <a href="https://github.blog/2022-09-14-8-things-you-didnt-know-you-could-do-with-github-copilot/" target="_blank">8 things you didn’t know you could do with GitHub Copilot</a>.

## Copilot!
Das ganze wirkt durchaus beeindruckend und funktioniert erstaunlich vernünftig sowie stressfrei. Dennoch ist es nur eine Hilfe. Der Name Copilot ist Programm und sollte auch so verstanden werden. Im Kontext der Programmierung steuert der Pilot (das seid ihr) das Flugzeug (das Programm). Er entscheidet, wo es hingeht und er hält das Flugzeug auf Kurs. 

Copilot gibt dabei wertvolle Unterstützung beim Start, der Landung und dem Flug, ist aber nicht entscheidend für den Erfolg dieses Fluges. Verlasst euch niemals nur auf den Vorschlag von Copilot. Überprüft, was er vorschlägt und ob das ganze wirklich passt.

## Ein Blick hinter die Kulissen
Nach dem ersten positiven Hype, den ich beim Ausprobieren entwickelt habe, stellte ich mir die Frage, woher die Vorschläge eigentlich kommen. 

Zum einen stammen viele Vorschläge vom aktuelle Repository, in dem ich gerade arbeite. Es werden zum Beispiel bereits implementierte Klassen und Methoden erkannt und die Übergabeparameter "sinnvoll" vorgeschlagen. Soweit ist das nichts Neues und das gleiche Vorgehen wie auch bei anderen solcher Tools.

Jedoch werden auch Vorschläge für ganze Codeblöcke gemacht, die keineswegs von meinem Code stammen können. Ein Blick auf die Funktionsbeschreibung von Copilot verrät, dass die Quelle andere Repositories auf GitHub sind. Laut GitHub handelt es sich dabei um öffentlichen Repositories, anhand derer die KI trainiert wird. 

Codex versucht Strukturen und Pattern von existierendem Code zu finden und erzeugt daraus unter anderem diese Vorschläge.  Darin liegt die *Macht* von Github Copilot. 


##  Die Dunkle Seite der Macht
Neben all dem positiven gibt es auch eine Schattenseite. Wie schon erwähnt, generiert der Copilot seine Vorschläge anhand von öffentlichen Repositories. 

Und das ist der große Knackpunkt. Darf Microsoft einfach den Code von anderen Repositories nutzen und damit Profit generieren? Viele der auf GitHub gehosteten Projekte wurden unter einer <a href="https://de.wikipedia.org/wiki/Copyleft" target="_blank">Copyleft-Lizenz</a> lizenziert. Damit sind diese Projekte nicht gemeinfrei, sondern stehen unter der <a href="https://de.wikipedia.org/wiki/Free/Libre_Open_Source_Software" target="_blank">"Free and Open Source Software"-Lizenz (FOSS)</a>.

Nutzt man diese Projekte, muss man den oder die Autoren nennen. Außerdem gibt es die Option, dass Software, die auf Grundlage dieser Open-Source-Software basiert, ebenfalls unter einer Copyleft-Lizenz lizenziert werden muss. Das ganze geschieht bei der Nutzung von GitHub Copilot nicht. Rein rechtlich ist Microsoft hier wohl auf der sicheren Seite, aber einen faden Beigeschmack hat das Ganze dennoch.

Das ist ein komplexes Thema, welches schon <a href="https://www.heise.de/meinung/Edit-Policy-GitHubs-KI-Copilot-ist-keine-Urheberrechtsverletzung-6128502.html" target="_blank">in anderen Artikeln</a> gut beleuchtet wurde. Dieses Thema wird in den kommenden Jahren noch für viel Gesprächsstoff sorgen. Nicht nur GitHub Copilot stößt an Grenzen der Ethik und des Rechts. Auch anderer solcher Tools werden diese Probleme bekommen. Denn eine KI, die gut funktionieren soll, muss auch gut trainiert werden. Das bedeutet, dass es viele Daten braucht. Die Grenzen werden sich wohl Stück für Stück verschieben und ggf. müssen neue Regelungen geschaffen werden, damit der Open-Source-Gedanke weiter bestehen kann.


## Fun Fact
Ich schreibe den Blogbeitrag aktuell im IntelliJ mit Markdown. Und während ich diese Zeilen schreibe, schlägt mir der Copilot meine Satzvervollständigung vor.  
Wir probieren mal, was passiert, wenn ich ab jetzt nur noch das nehme, was Copilot vorschlägt. Ich markiere alles, was ich getippt habe, dick. Und Los gehts:  
  
> **Ha**llo, ich bin ein neuer Entwickler. GitHub ist ein tolles Tool. **Da**s ist ein COPILOT-Tool.  
> **Zum Ab**schluss: **sei nochmal gesa**gt, dass ich ein COPILOT-Tool bin.  
  
Naja, wie sinnvoll das in Textanwendungen ist, sei mal dahingestellt.  :) 

GitHub Copilot – Pair Programming mit der KI

P5.JS: Zeichnen mit der Open-Source-JavaScript-Bibliothek

ArchUnit in der Praxis: Architektur sauber halten und optimieren

ArchUnit in practice: Keep your Architecture Clean

IT-Consultant & Developer

Junior IT-Consultant

Erfurt | Team

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Willkommen im Team Erfurt

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten