Wir sind eine zertifizierte B Corporation.

Cloud-Native

Data & KI

Produktentwicklung

Resilienz & 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?  

Senior Solution Architect

Cloud Native

Azure

Crossplane: GitOps für die Multi-Cloud

Wir erklären den Einsatz von dem Cloud-native Provisionierungswerkzeug Crossplane auf AWS und Azure.

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

Contact Us | Fragen an Mitarbeiter

Sprich mich an

Möchtest du dich über "Crossplane" und dessen Einsatz auf AWS und Azure austauschen?

Auf unserem Blog findest du viele Artikel zu Tech-Themen von unseren Mitarbeitenden. Vielleicht ist auch hier ein Thema für dich dabei. Schau gerne mal rein!

BLOG

codecentric Blog

WISSENS-HUB

Events – codecentric mittendrin

Community

Softwareentwicklung

Kultur

Der Softwerker

Hier gibt's noch mehr spannende Infos von uns für euch

Crossplane: GitOps für die Multi-Cloud | codecentric AG

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.

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.

Absenden

Crossplane: GitOps für die Multi-Cloud

Aus dem Inhalt:

Sprich mich an

Hier gibt's noch mehr spannende Infos von uns für euch

codecentric Blog

Events – codecentric mittendrin

Der Softwerker

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten