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

codecentric Team Leipzig

Unser codecentric Team am Standort Leipzig stellt sich vor.

Willkommen im Team Leipzig

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

Consultant & Developer

IT Consultant & Developer

Senior IT Consultant & Developer

<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

IT Consultant

Leipzig | 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 Leipzig

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten