Selfmade-RuLeZ/pet-clinic

A sample Spring-based application modified to be cloud-native, and to build and deploy using Red Hat's GitHub Actions.

Für den Workshop an Hochschulen, nutzen wir ein frei verfügbares Repository von Spring

Red Hat Actions - Spring Pet Clinic Sample

This is a fork of the Spring Pet Clinic which uses Red Hat's GitHub Actions to build an application image and deploy it to OpenShift as an example CI/CD workflow.

A Dockerfile and Helm Chart have been added to make this a cloud-ready version of the petclinic.

This workflow uses the following Red Hat Actions:

• buildah-action
• push-to-registry
• oc-login

It demos an end-to-end workflow which:

• Compiles a Java Spring web application
• Builds a container image
  • This action builds the image from scratch, but the buildah-action also supports Dockerfile builds.
  • An action for performing source-to-image builds is also available.
• Pushes that image to a registry
• Logs in to an OpenShift cluster
• Creates a Deployment, Service and Route to start a container and expose it to the internet
• Checks that the app is running successfully
• Tears down the test resources

This workflow runs on GitHub's Ubuntu runners, which come with oc 4.6.0 pre-installed.

If you're not using the Ubuntu runners, use oc-installer to install oc.

Try it yourself

To run the workflow on your fork, you have to replace a few environment variables and secrets with your own values.

1. Fork this repository.

2. Enable actions on your fork by navigating to the Actions tab and allowing actions to run.

3. Replace the environment variable values in the workflow yaml with your own.

   • The environment variables you must edit are at the top of the workflow file.
   • Edit the REGISTRY_USER and TEST_REGISTRY to point to your container registry.
     • For example, if you want to push to Dockerhub as john:
       • Set IMAGE_REGISTRY to docker.io.
       • Set REGISTRY_USER to john.
       • The password is stored in a secret called REGISTRY_PASSWORD - see below.
   • Edit the TEST_NAMESPACE to the namespace you want the workflow to issue oc commands against. The namespace must exist before the workflow runs.
     • You can also remove the TEST_NAMESPACE and the workflow will use the default for your user.

4. Add the necessary secrets in your forked repository's Settings.

   • Create a secret called REGISTRY_PASSWORD which contains the password, encrypted password, or token for the REGISTRY_USER you set up above.
   • See the oc-login Getting Started to determine the values for OPENSHIFT_SERVER and OPENSHIFT_TOKEN, and to read about the advantages and disadvantages of each authentication method.
     • The easiest way to retrieve these, if you're already logged in locally:
       • oc whoami --show-server for the OPENSHIFT_SERVER.
       • oc whoami --show-token for the OPENSHIFT_TOKEN.

5. Commit your changes and push to your fork.

6. The workflow will run to compile, build and deploy the petclinic.

7. To clean up the resources, log in locally, run helm ls, and delete the release that the workflow created.

   To have the workflow clean up after itself, set TEAR_DOWN: true in the env section at the top of the workflow.

Docker Build

Separate from the demo above, the project can also be built from its Dockerfile with:

mvn package && docker build . -t petclinic:latest
docker run -p 8080:8080 petclinic:latest

After the server starts, the app will be available at localhost:8080.