Skip to content

Commit 285705a

Browse files
banshee86vrbanshee86vr
authored
feat: deploy helm chart on vcluster (#6)
1 parent 8fdcc9d commit 285705a

File tree

13 files changed

+338
-35
lines changed

13 files changed

+338
-35
lines changed

‎.github/workflows/release.yml‎

Lines changed: 33 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,20 @@
11
on:
22
push:
3-
branches: [main]
4-
workflow_dispatch:
3+
branches:
4+
- "*"
55

66
permissions:
77
contents: write
88
pages: write
99
id-token: write
1010

11+
env:
12+
REGISTRY: ghcr.io
13+
1114
jobs:
1215
build:
1316
runs-on: ubuntu-latest
17+
if: github.ref == 'refs/heads/main'
1418
steps:
1519
- name: Checkout your repository using git
1620
uses: actions/checkout@v4
@@ -27,3 +31,30 @@ jobs:
2731
GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
2832
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
2933
run: npx semantic-release
34+
35+
build-docker-image:
36+
runs-on: ubuntu-latest
37+
steps:
38+
- name: Set up QEMU
39+
uses: docker/setup-qemu-action@v3
40+
- name: Set up Docker Buildx
41+
uses: docker/setup-buildx-action@v3
42+
- name: Login to GitHub Res
43+
uses: docker/login-action@v3
44+
with:
45+
registry: ${{ env.REGISTRY }}
46+
username: ${{ github.actor }}
47+
password: ${{ secrets.GITHUB_TOKEN }}
48+
- name: Get short SHA
49+
id: slug
50+
# run: echo "::set-output name=sha8::$(echo ${GITHUB_SHA} | cut -c1-8)"
51+
run: echo "SHA8=$(echo ${GITHUB_SHA} | cut -c1-8)" >> "$GITHUB_ENV"
52+
- name: Build and push
53+
uses: docker/build-push-action@v5
54+
with:
55+
context: "{{defaultContext}}:hello-world-app"
56+
platforms: linux/amd64,linux/arm64
57+
push: ${{ github.ref == 'refs/heads/main' && true || false }}
58+
tags: |
59+
${{ env.REGISTRY }}/${{ github.repository }}:${{ env.SHA8 }}
60+
${{ env.REGISTRY }}/${{ github.repository }}:latest

‎argo/README.md‎

Lines changed: 73 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,73 @@
1-
# Configuration of Argo entities
1+
# Trigger Argo Workflow Pipelines with Argo Events
2+
3+
Folders structure:
4+
5+
```
6+
.
7+
├── events
8+
│ └── README.md
9+
└── workflow
10+
├── README.md
11+
├── ci.yaml
12+
├── cd.yaml
13+
├── images
14+
│ └── ...
15+
└── lang
16+
└── go.yaml
17+
```
18+
19+
This CI/CD pipeline automates the build and deployment process for applications, focusing on a Dockerized GoLang application for this experiment. It consists of the following phases:
20+
21+
1. **Cloning Repository**: Fetches the source code from the git repository.
22+
2. **Building Application**: Utilizes the GoLang template to compile the Go application.
23+
3. **Building and Pushing Docker Image**: Packages the application into a Docker image and pushes it to the registry.
24+
4. **Preparing an ephemeral environment**: Prepares an ephemeral environment using vCluster where the user can test the application inside an isolated Kubernetes cluster
25+
5. **Deploy the application**: Deploy the application Helm chart on the vCluster just created
26+
27+
## Folder Structure
28+
- `ci.yaml`: Argo Workflow Template for the Docker image build and push phases:
29+
1. Clone the git repository.
30+
2. Build the application using the GoLang template.
31+
3. Build and push the Docker image to the registry.
32+
- `cd.yaml`: Argo Workflow Template for the deploy phases:
33+
1. Create a new vCluster
34+
2. Clone the repository with the application Helm chart
35+
3. Deploy on vCluster the application Helm chart
36+
- `lang/go.yaml`: Argo Workflow Template to build Go applications.
37+
38+
## Introduction
39+
This experiment provides an overview of Argo Workflow Pipelines and Argo Events, including their concepts, creation, configuration, and integration for effective workflow management and event-driven architecture.
40+
41+
### Argo Workflow Pipelines
42+
Argo Workflows is an open-source container-native workflow engine for orchestrating parallel jobs on Kubernetes. It enables users to define complex workflows as code, automating and orchestrating tasks efficiently.
43+
44+
#### Key Concepts:
45+
- **Workflow**: A directed acyclic graph (DAG) of tasks and dependencies, representing the workflow logic.
46+
- **Steps**: Individual units of work within a workflow, typically containerized tasks.
47+
- **Templates**: Reusable specifications for defining steps in workflows, allowing for modular and maintainable workflows.
48+
- **Artifacts**: Data or files produced by steps within the workflow.
49+
- **Parameters**: Inputs to templates or steps, allowing for dynamic workflow behavior.
50+
- **Outputs**: Results produced by workflows, including artifacts and status information.
51+
52+
#### Creation and Configuration:
53+
1. **Define Workflow**: Write YAML or JSON specifications defining the workflow, including steps, dependencies, inputs, and outputs.
54+
2. **Configure Resources**: Specify Kubernetes resources required for workflow execution, such as containers, volumes, and environment variables.
55+
3. **Handle Errors and Retries**: Implement error handling and retry mechanisms to ensure robustness and reliability.
56+
4. **Customize Workflow Logic**: Utilize advanced features like loops, conditionals, and parameterization to create flexible workflows.
57+
5. **Optimize Performance**: Fine-tune resource utilization, parallelism, and scheduling for optimal performance and resource efficiency.
58+
59+
### Argo Events
60+
Argo Events extends Kubernetes with event-driven architecture capabilities, enabling users to trigger workflows and other actions in response to events within the Kubernetes ecosystem or external systems.
61+
62+
#### Key Concepts:
63+
- **Event Sources**: Sources of events, including Kubernetes resources, messaging systems, webhooks, and custom triggers.
64+
- **Event Types**: Different types of events, such as resource creation, updates, or custom events defined by users.
65+
- **Event Sensors**: Components responsible for detecting and processing events, triggering associated actions.
66+
- **Handlers**: Actions or workflows executed in response to events, such as invoking Argo Workflows pipelines.
67+
68+
#### Creation and Configuration:
69+
1. **Define Event Sources**: Configure event sources to monitor for relevant events, specifying filters and event types.
70+
2. **Set Up Event Sensors**: Deploy event sensors to detect events from configured sources and route them to appropriate handlers.
71+
3. **Implement Handlers**: Define handlers to execute desired actions or workflows in response to detected events.
72+
4. **Monitor and Debug**: Monitor event processing and troubleshoot issues using logs, metrics, and observability tools.
73+
5. **Integrate with Workflows**: Integrate Argo Events with Argo Workflows pipelines to automate workflows based on detected events, enabling event-driven automation and orchestration.

‎argo/workflow/README.md‎

Lines changed: 174 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,178 @@
1-
# Configuration of Argo Workflow
1+
# Configuration of Argo Workflow entities
2+
3+
## Prerequisites:
4+
- Minikube
5+
- `kubectl` command-line tool installed and configured to connect to your Kubernetes cluster.
6+
- Helm version 3.x installed.
7+
8+
## Preparation steps:
9+
10+
### 1. Start minikube and install Argo Workflows using Helm:
11+
12+
```bash
13+
minikube start
14+
helm repo add argo https://argoproj.github.io/argo-helm
15+
helm install argo-workflows argo/argo-workflows
16+
```
17+
18+
This command installs Argo Workflows in the default namespace of your Kubernetes cluster.
19+
20+
### 2. Verify the Installation:
21+
22+
To check if the installation was successful, you can run:
23+
24+
```bash
25+
kubectl get pods -n argo
26+
```
27+
28+
You should see a list of pods running with names prefixed with `workflow-controller` and `argo-server`.
29+
30+
### 3. Patch argo-server authentication¶
31+
32+
As reported on the official documentation: https://argo-workflows.readthedocs.io/en/latest/quick-start/#patch-argo-server-authentication
33+
34+
The argo-server (and thus the UI) defaults to client authentication, which requires clients to provide their Kubernetes bearer token to authenticate. For more information, refer to the Argo Server Auth Mode documentation. We will switch the authentication mode to server so that we can bypass the UI login for now:
235

336
```bash
4-
kubectl create rolebinding default-admin --clusterrole=admin --serviceaccount=argo:default -n argo
37+
kubectl patch deployment \
38+
argo-server \
39+
--namespace argo \
40+
--type='json' \
41+
-p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
42+
"server",
43+
"--auth-mode=server"
44+
]}]'
545
```
646

7-
But: <https://argoproj.github.io/argo-workflows/workflow-rbac/>
47+
### 4. Access Argo Workflows UI (Optional):
48+
49+
Argo Workflows provides a web-based UI for managing and monitoring workflows. To access the UI, you need to expose it as a service:
50+
51+
```bash
52+
kubectl port-forward svc/argo-server -n argo 2746:2746
53+
```
54+
55+
Now you can access the Argo Workflows UI by navigating to `http://localhost:2746` in your web browser.
56+
57+
### 5. Add privileges to Argo service accounts
58+
59+
> Add this privileges to the Argo service accounts are recommended only for demo purposes. **IT'S STRONGLY NOT RECOMMENDED TO REPLICATE THIS CONFIGURATION IN PRODUCTION EVINRONMENTS.**
60+
61+
This command adds `cluster-admin` clusterrole to `argo:argo-server` and `argo:default`. In this way Argo Workflow can managed every kind of resources in every namespaces of the cluster.
62+
63+
```bash
64+
kubectl create clusterrolebinding argo-admin-server --clusterrole=cluster-admin --serviceaccount=argo:argo-server -n argo
65+
kubectl create clusterrolebinding argo-admin-default --clusterrole=cluster-admin --serviceaccount=argo:default -n argo
66+
```
67+
> In production evironments it's strongly recommended to create a dedicated role to these service accounts allowing only required verbs on the resources managed by the workflows.
68+
69+
### 6. Prepare secrets required by the pipelines
70+
71+
Just in case of private Git repository you can run this command to allow the clone command executed by the pipeline `ci.yaml`:
72+
73+
```bash
74+
kubectl create secret generic github-token -n argo --from-literal=token=.........
75+
```
76+
77+
This command create the secret that contains the credentials to push the Docker image to the registry:
78+
79+
```bash
80+
export DOCKER_USERNAME=******
81+
export DOCKER_TOKEN=******
82+
kubectl create secret generic docker-config --from-literal="config.json={\"auths\": {\"https://ghcr.io/\": {\"auth\": \"$(echo -n $DOCKER_USERNAME:$DOCKER_TOKEN|base64)\"}}}"
83+
```
84+
85+
### 7. Add Argo WorkflowTemplate manifests
86+
87+
```bash
88+
git clone https://github.com/banshee86vr/ephemeral-test-environment.git
89+
cd argo/workflow
90+
91+
kubectl apply -f ci.yaml
92+
kubectl apply -f lang/go.yaml
93+
kubectl apply -f cd.yaml
94+
```
95+
## Execution steps:
96+
97+
With all prerequisites met and Argo Workflows successfully deployed and configured, you dive into the execution steps to start creating and managing workflows.
98+
99+
### 8. Submit the CI pipeline
100+
101+
To submit the CI pipeline, you can use the [official APIs](https://argo-workflows.readthedocs.io/en/latest/rest-api/):
102+
103+
```bash
104+
<ArgoWorkflow URL>/api/v1/workflows/{namespace}/submit
105+
```
106+
107+
Or, alternatively, you can submit the workflow using the UI:
108+
109+
![Submit CI workflow via UI](images/1_ci_submit.png)
110+
111+
The CI pipeline performs these steps:
112+
113+
1. **Cloning Repository**: Fetches the source code from the git repository.
114+
2. **Building Application**: Utilizes the GoLang template to compile the Go application.
115+
3. **Building and Pushing Docker Image**: Packages the application into a Docker image and pushes it to the registry.
116+
117+
After the completion of all steps you can check the correct status of every step:
118+
119+
![CI workflow graph](images/2_ci_graph.png)
120+
121+
If all steps have been successfully completed, you can find a new version of the Docker image in your registry.
122+
123+
### 9. Submit the CD pipeline
124+
125+
To submit the CD pipeline, you can use the [official APIs](https://argo-workflows.readthedocs.io/en/latest/rest-api/):
126+
127+
```bash
128+
<ArgoWorkflow URL>/api/v1/workflows/{namespace}/submit
129+
```
130+
131+
Or, alternatively, you can submit the workflow using the UI:
132+
133+
![Submit CD workflow via UI](images/3_cd_submit.png)
134+
135+
The CD pipeline performs these steps:
136+
137+
1. **Preparing an ephemeral environment**: Prepares an ephemeral environment using vCluster where the user can test the application inside an isolated Kubernetes cluster
138+
2. **Deploy the application**: Deploy the application Helm chart on the vCluster just created
139+
140+
After the completion of all steps you can check the correct status of every step:
141+
142+
![CD workflow graph](images/4_cd_graph.png)
143+
144+
If all steps have been successfully completed, you can check the status of your application deployed on the vCluster just created
145+
146+
### 10. Access to the application
147+
148+
To check how to access to the application deployed on vCluster, you can run this commands to list all vCluster and to access it:
149+
150+
```bash
151+
$ vcluster list
152+
153+
NAME | CLUSTER | NAMESPACE | STATUS | VERSION | CONNECTED | CREATED | AGE | DISTRO
154+
------------------+----------+-----------------+---------+---------+-----------+-------------------------------+---------+---------
155+
demo-pr-request | minikube | demo-pr-request | Running | 0.19.0 | | xxxx-xx-xx xx:xx:xx +0100 CET | 1h8m49s | OSS
156+
157+
$ ➜ vcluster connect demo-pr-request --namespace demo-pr-request -- kubectl get pod -n demo-pr-request
158+
159+
NAME READY STATUS RESTARTS AGE
160+
demo-pr-request-hello-world-7f6d78645f-bjmjc 1/1 Running 0 7s
161+
```
162+
163+
As reported [here](https://www.vcluster.com/docs/using-vclusters/access) you can expose in different way the ephemeral vCluster created.
164+
165+
- **Via Ingress**: An Ingress Controller with SSL passthrough support will provide the best user experience, but there is a workaround if this feature is not natively supported.
166+
167+
- Kubernetes Nginx
168+
- Traefik Proxy
169+
- Emissary
170+
171+
Make sure your ingress controller is installed and healthy on the cluster that will host your virtual clusters. More details [here](https://www.vcluster.com/docs/using-vclusters/access#via-ingress)
172+
- **Via LoadBalancer service**: The easiest way is to use the flag `--expose` in vcluster create to tell vCluster to use a LoadBalancer service. It depens on the specific implementation of host kubernetes cluster.
173+
- **Via NodePort service**: You can also expose the vCluster via a NodePort service. In this case you have to create a NodePort service and change the `values.yaml` file to use for creation of the vCluster. More details [here](https://www.vcluster.com/docs/using-vclusters/access#via-nodeport-service)
174+
- **From Host Cluster**: In order to access the virtual cluster from within the host cluster, you can directly connect to the vCluster service. Make sure you can access that service and then create a kube config in the following form:
175+
176+
```bash
177+
vcluster connect my-vcluster -n my-vcluster --server=my-vcluster.my-vcluster --insecure --update-current=false
178+
```

0 commit comments

Comments
 (0)