You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using Kubernetes and containers, Red Hat OpenShift Dev Spaces is built on the open Eclipse Che project, providing a consistent, secure, and zero-configuration development environment for any member of the development or IT team.
4
+
Built on Eclipse Che, Red Hat OpenShift Dev Spaces provides a consistent, secure, zero-configuration development environment using Kubernetes and containers.
5
5
6
-
In this section, we will create our first workspace for coding. Please follow these steps:
6
+
In this section, we will create our first workspace:
7
7
8
-
* Open the `Gitea` git server (`demo-cicd` OpenShift project) and go to the `quarkus-petclinic` repository. Ensure that the `cnd` branch is selected.
8
+
* Open the `Gitea` git server (`demo-cicd` OpenShift project) and navigate to the `quarkus-petclinic` repository. Ensure the `cnd` branch is selected.
9
9
10
-
* Open the `devfile.yaml`, click on `Raw`, and copy the URL.
10
+
* Open the `devfile.yaml`, click `Raw`, and copy the URL.
11
11
12
12
image::devspaces/devspaces-1.png[]
13
13
14
-
* Open the Red Hat OpenShift Dev Spaces dashboard (`demo-devspaces` OpenShift project) and click on `Create Workspace`.
14
+
* Open the Red Hat OpenShift Dev Spaces dashboard (`demo-devspaces` OpenShift project) and click `Create Workspace`.
15
15
16
16
image::devspaces/devspaces-2.png[]
17
17
18
-
* Paste the URL of the `devfile.yaml` into the `Git Repo URL` field, then click `Create & Open`.
18
+
* Paste the `devfile.yaml`URL into the `Git Repo URL` field and click `Create & Open`.
OpenShift GitOps is a continuous deployment (CD) tool that uses Argo CD to manage and deploy our applications. With GitOps, we can automatically deploy our applications using a Git-based approach. This allows us to have an auditable, versioned, and repeatable deployment process.
4
+
OpenShift GitOps leverages Argo CD to manage and deploy applicationsusing a Git-based approach, enabling auditable, versioned, and repeatable deployments.
5
5
6
-
Argo CD is a Kubernetes-native tool that provides us with a declarative way to manage our application configurations. It continuously monitors our Git repository for changes and automatically deploys any changes to our target environment. We can define our desired state of the application in a declarative way using Kubernetes manifests, and Argo CD will make sure that the deployed state matches the desired state.
6
+
Argo CD continuously monitors our Git repository for changes and ensures the deployed state matches the declared desired state defined in Kubernetes manifests. This allows for scalable, resilient, and declarative application management, with a clear separation of duties between developers and operators.
7
7
8
-
One of the benefits of using OpenShift GitOps with Argo CD is that it allows us to implement a robust deployment process that is scalable, repeatable, and resilient. By leveraging Kubernetes native tools and best practices, we can easily manage our applications' entire lifecycle, from development to production. Additionally, GitOps allows us to implement a separation of duties between developers and operators, making it easier to manage and maintain our applications.
8
+
In the previous section, Tekton handled the CI cycle, building the application image and leaving the platform ready for CD.
9
9
10
-
OpenShift GitOps with Argo CD can help us streamline our deployment process, minimize human error, and improve our overall efficiency. It provides us with a declarative and Git-based approach to managing our application configurations, making it easier to manage and maintain our applications.
10
+
In this section, we use the `quarkus-petclinic-config` repository, which contains configuration files for deploying the application with the previously built image across environments.
11
11
12
-
In the previous section, we used Tekton for our CI cycle, building the image and leaving the platform ready to perform our CD cycle.
13
-
14
-
Up to this point, we had seen our application code repository `quarkus-petclinic`. In this section, we introduce the other available repository, `quarkus-petclinic-config`; it contains the configuration of our application, which will use the same base image built earlier, in the different environments.
15
-
16
-
If we look at the repository, we will see that in one of the pipeline stages, a commit was made to the file `environments/dev/kustomization.yaml` (branch `cnd`), indicating that the new image digest is `00d58...`, which if we remember, is the same one we noted in the previous section.
17
-
18
-
This means that Argo CD will take care of updating the platform and updating the associated Kubernetes objects, such as the `Deployment` object where the reference to the new image is located. In other words, it will deploy the new image.
19
-
20
-
The image is available in the `demo-dev` project. Let's check what was mentioned, following the steps below:
21
-
22
-
* Open the git repository for the configuration of the application, which is `quarkus-petclinic-config`, branch `cnd`, and view the `environments/dev/kustomization.yaml` file. We observe that the latest code commit updates the sha of the image.
12
+
* Open the `quarkus-petclinic-config` repository, branch `cnd`, and inspect `environments/dev/kustomization.yaml`. The latest commit updates the image digest (`00d58...`), corresponding to the image built in CI.
23
13
24
14
image::gitops/gitops-1.png[]
25
15
26
-
* Open the Argo CD dashboard. We see the two applications that are being synchronized.
16
+
* Open the Argo CD dashboard to see the synchronized applications.
27
17
28
18
image::gitops/gitops-2.png[]
29
19
30
-
* Click on `dev-quarkus-petclinic`.
20
+
* Click `dev-quarkus-petclinic`.
31
21
32
-
* At the top, we see that it indicates that it is synchronized `To cnd (xxx)` where `cnd` is the branch of the repository, and `xxx` is the commit hash. We see that the hash matches the one we had seen before in the first point.
22
+
* At the top, verify it shows `Synchronized To cnd (xxx)`, where `xxx` is the commit hash from the Git repository, matching the previous step.
33
23
34
24
image::gitops/gitops-3.png[]
35
25
36
-
* Click on the pod component with the name`quarkus-petclinic-xxxx`.
26
+
* Click the pod component `quarkus-petclinic-xxxx`.
37
27
38
-
* In the SUMMARY, under the IMAGES section, we verify that the version with the new sha is indeed deployed.
28
+
* In the SUMMARY under IMAGES, verify the deployed image has the updated sha.
39
29
40
30
image::gitops/gitops-4.png[]
41
31
42
-
* If we go to the OpenShift console, we can check that the pod and its route are already deployed with the new image version, in the `demo-dev` project.
32
+
* In the OpenShift console, check the pod and route are deployed with the new image in the `demo-dev` project.
43
33
44
34
image::gitops/gitops-5.png[]
45
35
46
-
At this point, let's assume that we have already done all the necessary tests in the development environment (`demo-dev`). Everything is working correctly and we want to promote the image to the stage environment.
36
+
Once tests pass in the development environment, we can promote the image to the stage environment. The CI pipeline creates a Pull Request in the `cnd` branch of `quarkus-petclinic-config` updating the image sha in `environments/stage/kustomization.yaml`.
47
37
48
-
For context, in the pipeline we ran in the CI section, the final stage created a Pull Request (PR) in the `cnd` branch of the `quarkus-petclinic-config` configuration repository. This change, waiting to be approved and merged, modifies the `sha` of the current image, just like the case we saw for development, but with the difference that the change is made to the `environments/stage/kustomization.yaml` file.
49
-
50
-
As we saw before, Argo CD also synchronizes that file, which appears as the application name `stage-quarkus-petclinic` in the Argo CD dashboard.
51
-
52
-
Let's see how to promote the image to the stage environment. We will follow the following steps:
53
-
54
-
* Open the git repository for the configuration of the `quarkus-petclinic` application, branch `cnd`, and view the `environments/stage/kustomization.yaml` file. We observe that a PR is pending.
38
+
* Open the `environments/stage/kustomization.yaml` file in the repository; a PR is pending.
55
39
56
40
image::gitops/gitops-6.png[]
57
41
@@ -63,20 +47,20 @@ image::gitops/gitops-7.png[]
63
47
64
48
image::gitops/gitops-8.png[]
65
49
66
-
Let's now check that after the PR merge, Argo CD effectively updates the state of the platform, updating the involved Kubernetes objects and leaving as a final scenario the new image deployed in the demo-stage project.
50
+
After merging, Argo CD updates the platform state and deploys the new image in the `demo-stage` project.
67
51
68
-
* Open the Argo CD dashboard and select the stage-quarkus-petclinic application.
52
+
* In the Argo CD dashboard, select the `stage-quarkus-petclinic` application.
69
53
70
54
image::gitops/gitops-9.png[]
71
55
72
-
* Verify that the synchronized hash is the same as the one in the git repository.
56
+
* Verify the synchronized hash matches the Git repository.
73
57
74
58
image::gitops/gitops-10.png[]
75
59
76
-
* Check that the deployed pod has the desired `sha`.
60
+
* Confirm the deployed pod uses the desired image sha.
77
61
78
62
image::gitops/gitops-11.png[]
79
63
80
-
* In the OpenShift console, we can see the new pod deployed with the new image.
81
-
64
+
* In the OpenShift console, check the new pod is running with the updated image.
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/index.adoc
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,12 +5,12 @@
5
5
[.text-center.strong]
6
6
== Introduction
7
7
8
-
Welcome to this workshop focused on cloud-native development with OpenShift using tools from the Red Hat stack.
8
+
Welcome to this workshop focused on cloud-native development with OpenShift using Red Hat tools.
9
9
10
-
In this workshop, we will explore how to build and deploy applications in a cloud-native way, leveraging the power of containerization, Kubernetes, and DevOps principles.
10
+
In this workshop, we will explore how to build and deploy applications in a cloud-native way, leveraging containerization, Kubernetes, and DevOps principles.
11
11
12
-
We will cover various topics such as deploying and scaling applications, monitoring and logging, continuous integration and delivery, and more.
12
+
Topics covered include deploying and scaling applications, monitoring and logging, continuous integration and delivery, and more.
13
13
14
-
By the end of this workshop, you will have gained a solid understanding of how to develop, deploy and manage cloud-native applications on OpenShift using the Red Hat stack of tools.
14
+
By the end of this workshop, you will have gained a solid understanding of how to develop, deploy, and manage cloud-native applications on OpenShift using Red Hat technologies.
15
15
16
-
IMPORTANT: This is not an official guide or workshop provided by Red Hat. For more information on trainingor guidelines related to this topic or product, please reach out to your designated Red Hat representative.
16
+
IMPORTANT: This is not an official guide or workshop provided by Red Hat. For official training, documentation, or guidance related to this product, please contact your designated Red Hat representative.
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/pipelines.adoc
+21-12Lines changed: 21 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,46 +3,55 @@ include::_attributes.adoc[]
3
3
4
4
In this section, we will explore how to implement Continuous Integration (CI) with OpenShift Pipelines, which leverages Tekton underneath. Pipeline runs are defined as code, allowing for greater flexibility and easier management.
5
5
6
-
In our setup, we have pipelines defined as code within the .tekton directory of our application, available in Git. Our Git repository is configured with a webhook for commits, which triggers a request to the URL of the Pipelines as Code Controller to execute the pipeline.
6
+
In our setup, pipelines are defined as code within the `.tekton` directory of our application repository in Git. The repository is configured with a webhook for commits, which triggers a request to the Pipelines as Code Controller to execute the pipeline.
7
7
8
8
Navigate to the `quarkus-petclinic` repository and inspect the `.tekton` directory files.
9
9
10
10
image::pipelines/pipelines-1.png[]
11
11
12
-
Try to understand the `yaml` files. You may want to check the Pipelines as Code and Tekton documentation:
12
+
Try to understand the `yaml` files. Useful references:
13
13
14
14
https://pipelinesascode.com/
15
15
16
16
https://tekton.dev/docs/
17
17
18
-
These pipeline runs are responsible for cloning the Git code repository, configuring Maven, running unit tests, performing Sonar analysis, uploading the application release to Nexus, building the container image using source to image (s2i), pushing it to the internal OpenShift registry, updating the manifests for Argo CD detection, and finally, opening a pull request in the repository for verification before deploying the image to stage.
18
+
These pipeline runs are responsible for:
19
19
20
-
As someone with experience in DevOps and CI/CD processes, I find OpenShift Pipelines and Tekton to be a powerful toolset for building and automating the entire software delivery pipeline. The ability to define pipeline runs as code is a game-changer, as it provides a level of transparency and repeatability that was not possible before.
20
+
* Cloning the Git repository.
21
+
* Configuring Maven.
22
+
* Running unit tests.
23
+
* Performing Sonar analysis.
24
+
* Uploading the application release to Nexus.
25
+
* Building the container image using source-to-image (s2i).
26
+
* Pushing it to the internal OpenShift registry.
27
+
* Updating manifests for Argo CD detection.
28
+
* Opening a pull request in the repository for verification before deploying to stage.
21
29
22
-
Now, let's take a look at how it works:
30
+
OpenShift Pipelines and Tekton provide a transparent, repeatable, and automated CI/CD process by defining pipeline runs as code.
23
31
24
-
* Let's make a change in the source code to see how the pipeline is triggered.
32
+
Steps to see it in action:
25
33
26
-
* Open the pom.xml file and, for example, increment the version of the release.
34
+
* Make a change in the source code to trigger the pipeline.
35
+
* Open `pom.xml` and increment the version of the release.
27
36
28
37
image::pipelines/pipelines-2.png[]
29
38
30
-
* Save the changes by committing to the repository.
39
+
* Commit the changes to the repository.
31
40
32
41
image::pipelines/pipelines-3.png[]
33
42
34
-
* Go to the OpenShift web console, `demo-cicd` workspace, in Pipelines, under the PipelineRuns tab. We see the pipeline running and open it.
43
+
* In the OpenShift web console, navigate to the `demo-cicd` workspace, Pipelines → PipelineRuns. The pipeline will appear running.
35
44
36
45
image::pipelines/pipelines-4.png[]
37
46
38
47
image::pipelines/pipelines-5.png[]
39
48
40
-
* We can see the pipeline running, with its different stages, by clicking on it, we can see the logs. We wait for the pipeline run to complete.
49
+
* Click on the running pipeline to view its stages and logs. Wait for it to complete.
41
50
42
51
image::pipelines/pipelines-6.png[]
43
52
44
-
* Click on the `build-image` stage to review the logs. Take note of the `sha256`given to the image. In our example, `00d58...`.
53
+
* Click on the `build-image` stage to review logs. Take note of the `sha256`assigned to the image, e.g., `00d58...`.
45
54
46
55
image::pipelines/pipelines-7.png[]
47
56
48
-
At this point, we have successfully executed our CI cycle with the help of Tekton. It has taken care of running the different steps of the cycle, including building the application image. It has also created a commit in the configuration repository, which we will further detail in the next section dedicated to CD.
57
+
At this point, the CI cycle has been successfully executed using Tekton. The pipeline has automated all steps, including building the application image, and has created a commit in the configuration repository. The next section will cover CD.
0 commit comments