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
Copy file name to clipboardExpand all lines: docs/2-attack-of-the-pipelines/1-sealed-secrets.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,10 @@
2
2
3
3
When we say GitOps, we say _"if it's not in Git, it's NOT REAL"_. But how are we going to store our sensitive data like credentials in Git repositories, where many people can access?! Sure, Kubernetes provides a way to manage secrets, but the problem is that it stores the sensitive information as a base64 string - anyone can decode the base64 string! Therefore, we cannot store `Secret` manifest files openly. We use an open-source tool called Sealed Secrets to address this problem.
4
4
5
-
Sealed Secrets allows us to _seal_ Kubernetes secrets by using a utility called `kubeseal`. The `SealedSecrets` are Kubernetes resources that contain encrypted `Secret` object that only the controller can decrypt. Therefore, a `SealedSecret` is safe to store even in a public repository.
5
+
Sealed Secrets allows us to _seal_ Kubernetes secrets by using a utility called `kubeseal`. The `SealedSecrets` are Kubernetes resources that contain an encrypted `Secret` object that only the controller can decrypt. Therefore, a `SealedSecret` is safe to store even in a public repository.
6
6
7
7
<pclass="warn">
8
-
⛷️ <b>NOTE</b> ⛷️ - If you switch to a different Dev Spaces Workspaces environment, please run below commands before going forward.
8
+
⛷️ <b>NOTE</b> ⛷️ - If you switch to a different Dev Spaces Workspace environment, please run below commands before going forward.
9
9
</p>
10
10
11
11
```bash
@@ -16,7 +16,7 @@ git pull
16
16
17
17
### Sealed Secrets in action
18
18
19
-
1. The observant among you will have noticed that in the previous exercise we created a secret for git and added it to the cluster WITHOUT putting it in git...😳 Let's start by fixing this and sealing our Git credentials so they can be safely checked in to the code. First, we'll create the secret in a tmp directory. Make sure you have your gitlab user and PAT from the previous exercise set in your environment
19
+
1. The observant among you will have noticed that in the previous exercise we created a secret for git and added it to the cluster WITHOUT putting it in git...😳 Let's start by fixing this and sealing our Git credentials so they can be safely checked into the code. First, we'll create the secret in a tmp directory. Make sure you have your gitlab user and PAT from the previous exercise set in your environment
20
20
21
21
```bash
22
22
echo${GITLAB_USER}
@@ -67,7 +67,7 @@ EOF
67
67
cat /tmp/sealed-git-auth.yaml
68
68
```
69
69
70
-
We should now see the secret is sealed, so it is safe forus to storein our repository. It should look something a bit like this, but with longer password and username output.
70
+
We should now see the secret is sealed, so it is safe forus to storein our repository. It should look something like this, but with longer password and username output.
71
71
72
72
<div class="highlight" style="background: #f7f7f7">
73
73
<pre><code class="language-yaml">
@@ -107,7 +107,7 @@ EOF
107
107
source_ref: "1.0.3"
108
108
values:
109
109
secrets:
110
-
# Additional secrets will be added to this list along the exercises.
110
+
# Additional secrets will be added to this list throughout the exercises.
9. You can also verify it's been synced to Jenkins now by opening `Jenkins -> Manage Jenkins -> Manage Credentials` to view the `<TEAM_NAME>-ci-cd-git-auth` credential
151
+
9. You can also verify it's been synced to Jenkins now by opening `Jenkins -> Manage Jenkins -> Credentials` to view the `<TEAM_NAME>-ci-cd-git-auth` credential
152
152
153
153
```bash#test
154
154
echo https://$(oc get route jenkins --template='{{ .spec.host }}' -n ${TEAM_NAME}-ci-cd)
Copy file name to clipboardExpand all lines: docs/2-attack-of-the-pipelines/2-app-of-apps.md
+24-25Lines changed: 24 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,15 +2,15 @@
2
2
3
3
We need a way to bundle up all of our applications and deploy them into each environment. Each PetBattle application has its own Git repository and Helm chart, making it easier to code and deploy independently from other apps.
4
4
5
-
A developer can get the same experience and end result installing an application chart using `helm install` as our fully automated pipeline. This is important from a useability perspective. Argo CD has great support for all sorts of packaging formats that suit Kubernetes deployments, `Kustomize`, `Helm`, as well as just raw YAML files. Because Helm is a template language, we can mutate the Helm chart templates and their generated Kubernetes objects with various values allowing us to configure them with a custom configuration per environment.
5
+
A developer can get the same experience and end result installing an application chart using `helm install` as our fully automated pipeline. This is important from a usability perspective. Argo CD has great support for all sorts of packaging formats that suit Kubernetes deployments, `Kustomize`, `Helm`, as well as just raw YAML files. Because Helm is a template language, we can mutate the Helm chart templates and their generated Kubernetes objects with various values allowing us to configure them with a custom configuration per environment.
6
6
7
-
We deploy each of our applications using an Argo CD `application` definition. We use one Argo CD `application` definition for every environment in which we wish to deploy the application. We make use of Argo CD `app of apps pattern` to bundle all of these all up; some might call this an application suite or a system! In PetBattle we generate the app-of-apps definitions using a Helm chart.
7
+
We deploy each of our applications using an Argo CD `application` definition. We use one Argo CD `application` definition for every environment in which we wish to deploy the application. We make use of Argo CD `app-of-apps pattern` to bundle all of these up; some might call this an application suite or a system! In Pet Battle we generate the app-of-apps definitions using a Helm chart.
8
8
9
9
### Deploying Pet Battle - Keycloak
10
10
11
11
> In this exercise we'll deploy PetBattle and a supporting piece of tech it uses (Keycloak) using the same pattern. We'll deploy PetBattle to two environments - `test` and `stage` by configuring the values files in `pet-battle/stage/values.yaml` && `pet-battle/test/values.yaml`
12
12
13
-
1. In your IDE - open `tech-exercises/values.yaml` file at the root of this project and **swap**`enabled: false` to `enabled: true` as shown below for each of the app-of-pb definitions:
13
+
1. In your IDE - open `tech-exercise/values.yaml` file at the root of this project and **swap**`enabled: false` to `enabled: true` as shown below for each of the app-of-pb definitions:
14
14
15
15
<divclass="highlight"style="background: #f7f7f7">
16
16
<pre><codeclass="language-yaml">
@@ -102,6 +102,7 @@ We deploy each of our applications using an Argo CD `application` definition. We
102
102
image_version: latest # container image version
103
103
hpa:
104
104
enabled: false
105
+
servicemonitor: false
105
106
106
107
pet-battle:
107
108
name: pet-battle
@@ -118,7 +119,7 @@ We deploy each of our applications using an Argo CD `application` definition. We
118
119
```bash#test
119
120
# test
120
121
if [[ $(yq e '.applications[] | select(.name=="pet-battle-api") | length' /projects/tech-exercise/pet-battle/test/values.yaml) < 1 ]]; then
@@ -138,7 +139,7 @@ We deploy each of our applications using an Argo CD `application` definition. We
138
139
sed -i '/^# Pet Battle Apps/d' /projects/tech-exercise/pet-battle/stage/values.yaml
139
140
```
140
141
141
-
2. The frontend needs to have some configuration applied to it. This could be packaged up in the helm chart or baked into the image - BUT we should really apply configuration as *code*. We should build our apps once so they can be initialized in many environments with configuration supplied at runtime. For the frontend, this means supplying the information about where the API live. We use ArgoCD to manage our application deployments, hence we should update the values supplied to this chart as such.
142
+
2. The frontend needs to have some configuration applied to it. This could be packaged up in the helm chart or baked into the image - BUT we should really apply configuration as *code*. We should build our apps once so they can be initialized in many environments with configuration supplied at runtime. For the frontend, this means supplying the information about where the API lives. We use ArgoCD to manage our application deployments, hence we should update the values supplied to this chart as such.
142
143
143
144
```bash#test
144
145
export JSON="'"'{
@@ -239,30 +240,28 @@ We deploy each of our applications using an Argo CD `application` definition. We
Copy file name to clipboardExpand all lines: docs/2-attack-of-the-pipelines/3-the-pipelines.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
## Pipelines
2
2
3
-
Why creating pipelines:
3
+
Why create pipelines:
4
4
5
5
* Assurance - drive up code quality and remove the need for dedicated deployment / release management teams
6
6
* Freedom - allow developers to take ownership of how and when code gets built and shipped
@@ -33,7 +33,7 @@ Choose your own adventure! Each group will get to perform similar tasks:
33
33
| * We need to fork PetBattle (clone from GitHub and push to GitLab) | * We need to fork PetBattle API (clone from GitHub and push to GitLab) |
34
34
| * Update `Jenkinsfile` task to leave out some stuff for participants | * Update Tekton task to leave out some stuff for participants |
35
35
| * Add a webhook into GitLab repositories for triggering jobs | * Add webhook into GitLab repositories for triggering jobs |
36
-
| * Update `pet-battle/stage/values.yaml` && `pet-battle/test/values.yaml` with services information. (That's where two teams integrate their work.) | * Update `pet-battle/stage/values.yaml` && `pet-battle/test/values.yaml` with services information. (That's where two teams integrate their work.)
36
+
| * Update `pet-battle/stage/values.yaml` && `pet-battle/test/values.yaml` with services information. (That's where two groups integrate their work.) | * Update `pet-battle/stage/values.yaml` && `pet-battle/test/values.yaml` with services information. (That's where two groups integrate their work.)
37
37
| * By updating version files (pom.xml etc), kick off the pipelines | * By updating version files (pom.xml etc), kick off the pipelines |
0 commit comments