Overview
Cloud environments such as Kubernetes and OpenShift benefit from processes different from the ones developers traditionally used for standalone applications. Automation becomes a necessity in large environments and fast-changing configurations of hosts.
Getting GitOps is a practical guide through the jungle of modern development with Kubernetes, with a focus on application distribution via continuous integration/continuous delivery (CI/CD) and GitOps on Red Hat OpenShift. It starts by defining a common use case and taking you through it from beginning to end.
Download the e-book to learn:
- How to install and use Quarkus for Java development
- How to configure an application to use a PostgreSQL database in a Kubernetes environment
- Basic Kubernetes files
- OpenShift Templates
- The Kustomize configuration management tool
- The Docker, Podman, Buildah, and Skopeo build tools
- Basic Helm charts and subcharts
- Kubernetes Operators
- CI/CD with Tekton
- CI/CD with OpenShift Pipelines
- GitOps with Argo CD
- Tekton security
Excerpt
Preparing for CI/CD
Until now, everything you did was for local development. With just a few lines of code, you were able to create a complete database client. You did not even have to worry about setting up a local database for testing. But how can you specify real database properties when entering test or production stages?
Quarkus supports configuration profiles. Properties marked with a given profile name are used only if the application runs in that particular profile. By default, Quarkus supports the following profiles:
dev: Gets activated when you run your application via quarkus devtest: Gets activated when you are running testsprod: The default profile if the application is not started in the dev profile
In our case, you want to specify database-specific properties only in prod mode. If you specified a database URL in dev mode, for example, Quarkus would try to use that database server instead of starting the corresponding Dev Services as you want.
Our configuration therefore is:
# only when we are developing
%dev.quarkus.hibernate-orm.database.generation=drop-and-create
%dev.quarkus.hibernate-orm.sql-load-script=import.sql
# only in production
%prod.quarkus.hibernate-orm.database.generation=update
%prod.quarkus.hibernate-orm.sql-load-script=no-file
# Datasource settings...
# note, we only set those props in prod mode
quarkus.datasource.db-kind=postgresql
%prod.quarkus.datasource.username=${DB_USER}
%prod.quarkus.datasource.password=${DB_PASSWORD}
%prod.quarkus.datasource.jdbc.url=jdbc:postgresql://${DB_HOST}/${DB_DATABASE}Quarkus also supports the use of property expressions [1.10] For instance, if your application is running on Kubernetes, you might want to specify the datasource username and password via a secret. In this case, use the ${PROP_NAME} expression format to refer to the property that was set in the file. Those expressions are evaluated when they are read. The property names are either specified in the application.properties file or come from environment variables.
Your application is now prepared for CI/CD (continuous integration/continuous delivery) and production. We’ll get to that later in this book.
Related E-books
