ArgoCD Tutorial - Getting Started II > OpenShift 자료실

안녕하세요.
 
꿈꾸는여행자입니다.

 

지난 내역과 계속하여 

OpenShift 환경에서 자주 사용되는 ArgoCD 관련 사항을 다루고자 합니다.

 

해당 주제에서는 Redhat에서 제공하는 Tutorial 기반으로 테스트하여 ArgoCD를 처음 적용하는 부분에 많은 도움이 될것으로 보입니다. 

이번 항목은 사전 준비 단계로 

Pod, Network 및 Git 준비 관련된 내용입니다. 

상세 내역은 아래와 같습니다.


감사합니다.

> 아래 

0.2. Pod

0.2.1. nodejs - ubi8/nodejs-14 - Building an application using a Dockerfile

* Building an application using a Dockerfile

   * https://github.com/sclorg/s2i-nodejs-container/tree/master/18

   * https://github.com/sclorg/s2i-nodejs-container/tree/master/14

   * Compared to the Source-to-Image strategy, using a Dockerfile is a more flexible way to build a Node.js container image with an application. Use a Dockerfile when Source-to-Image is not sufficiently flexible for you or when you build the image outside of the OpenShift environment.

   * To use the Node.js image in a Dockerfile, follow these steps:

0.2.1.1. Pull a base builder image to build on

podman pull ubi8/nodejs-14

[root@bastion 20230105_podman]# pwd

/root/Documents/Work/20230105_podman

[root@bastion 20230105_podman]# podman pull ubi8/nodejs-14

Resolved "ubi8/nodejs-14" as an alias (/etc/containers/registries.conf.d/001-rhel-shortnames.conf)

Trying to pull registry.access.redhat.com/ubi8/nodejs-14:latest...

Getting image source signatures

Checking if image destination supports signatures

Copying blob 2cf6011ee4f7 done  

Copying blob 264562afb4ff done  

Copying blob 417723e2b937 done  

Copying config ccf47621e2 done  

Writing manifest to image destination

Storing signatures

ccf47621e29cf094136eb5a81dab5b8659310239198413be9a942bfac3f1d938

[root@bastion 20230105_podman]#

An UBI image ubi8/nodejs-14 is used in this example. This image is usable and freely redistributable under the terms of the UBI End User License Agreement (EULA). See more about UBI at UBI FAQ.

0.2.1.2. Pull an application code

An example application available at https://github.com/sclorg/nodejs-ex.git is used here. Feel free to clone the repository for further experiments.

git clone https://github.com/sclorg/nodejs-ex.git app-src

[root@bastion 20230105_podman]# git clone https://github.com/sclorg/nodejs-ex.git app-src

Cloning into 'app-src'...

remote: Enumerating objects: 673, done.

remote: Total 673 (delta 0), reused 0 (delta 0), pack-reused 673

Receiving objects: 100% (673/673), 264.46 KiB | 1.33 MiB/s, done.

Resolving deltas: 100% (263/263), done.

[root@bastion 20230105_podman]#

0.2.1.3. Prepare an application inside a container

* This step usually consists of at least these parts:

   * putting the application source into the container

   * installing the dependencies

   * setting the default command in the resulting image

* For all these three parts, users can either setup all manually and use commands nodejs and npm explicitly in the Dockerfile (3.1.), or users can use the Source-to-Image scripts inside the image (3.2.; see more about these scripts in the section "Source-to-Image framework and scripts" above), that already know how to set-up and run some common Node.js applications.

0.2.1.3.1. To use your own setup, create a Dockerfile with this content:

vi Dockerfile 

[root@bastion 20230105_podman]# cat Dockerfile 

FROM ubi8/nodejs-14

# Add application sources

ADD app-src .

# Install the dependencies

RUN npm install

# Run script uses standard ways to run the application

CMD npm run -d start

[root@bastion 20230105_podman]#

0.2.1.3.2. To use the Source-to-Image scripts and build an image using a Dockerfile, create a Dockerfile with this content:

* 해당 내용으로 적용

vi Dockerfile

[root@bastion 20230105_podman]# cat Dockerfile

FROM ubi8/nodejs-14

# Add application sources to a directory that the assemble script expects them

# and set permissions so that the container runs without root access

USER 0

ADD app-src /tmp/src

RUN chown -R 1001:0 /tmp/src

USER 1001

# Install the dependencies

RUN /usr/libexec/s2i/assemble

# Set the default command for the resulting image

CMD /usr/libexec/s2i/run

[root@bastion 20230105_podman]#

0.2.1.4. Build a new image from a Dockerfile prepared in the previous step

podman build -t node-app .

podman build -t \

    registry.test.example.com:5000/nodejs/nodejs-sample-app:latest .

podman push \

    --tls-verify=false \

    registry.test.example.com:5000/nodejs/nodejs-sample-app:latest

[root@bastion 20230105_podman]# podman build -t \

    registry.test.example.com:5000/nodejs/nodejs-sample-app:latest .

STEP 1/7: FROM ubi8/nodejs-14

STEP 2/7: USER 0

--> cc6d7ecb1f6

STEP 3/7: ADD app-src /tmp/src

--> fdf0d6156c1

STEP 4/7: RUN chown -R 1001:0 /tmp/src

--> 8f472072395

STEP 5/7: USER 1001

--> 5e0a4527633

STEP 6/7: RUN /usr/libexec/s2i/assemble

---> Installing application source ...

---> Installing all dependencies

npm WARN deprecated mkdirp@0.5.1: Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)

npm WARN deprecated jade@0.26.3: Jade has been renamed to pug, please install the latest version of pug instead of jade

npm WARN deprecated to-iso-string@0.0.2: to-iso-string has been deprecated, use @segment/to-iso-string instead.

npm WARN deprecated bson@1.0.9: Fixed a critical issue with BSON serialization documented in CVE-2019-2391, see https://bit.ly/2KcpXdo for more details

npm WARN deprecated superagent@1.2.0: Please upgrade to v7.0.2+ of superagent.  We have fixed numerous issues with streams, form-data, attach(), filesystem errors not bubbling up (ENOENT on attach()), and all tests are now passing.  See the releases tab for more information at <https://github.com/visionmedia/superagent/releases>.

npm WARN deprecated mkdirp@0.3.0: Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)

npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

npm WARN deprecated formidable@1.0.14: Please upgrade to latest, formidable@v2 or formidable@v3! Check these notes: https://bit.ly/2ZEqIau

> ejs@2.7.4 postinstall /opt/app-root/src/node_modules/ejs

> node ./postinstall.js

Thank you for installing EJS: built with the Jake JavaScript build tool (https://jakejs.com/)

npm notice created a lockfile as package-lock.json. You should commit this file.

added 129 packages from 345 contributors and audited 129 packages in 6.596s

7 packages are looking for funding

  run `npm fund` for details

found 18 vulnerabilities (2 low, 4 moderate, 9 high, 3 critical)

  run `npm audit fix` to fix them, or `npm audit` for details

---> Building in production mode

---> Pruning the development dependencies

audited 129 packages in 0.959s

7 packages are looking for funding

  run `npm fund` for details

found 18 vulnerabilities (2 low, 4 moderate, 9 high, 3 critical)

  run `npm audit fix` to fix them, or `npm audit` for details

/tmp is not a mountpoint

---> Cleaning the /tmp/npm-*

/opt/app-root/src/.npm is not a mountpoint

---> Cleaning the npm cache /opt/app-root/src/.npm

--> 3a425f2eeee

STEP 7/7: CMD /usr/libexec/s2i/run

COMMIT registry.test.example.com:5000/nodejs/nodejs-sample-app:latest

--> 2f8b2441d5b

Successfully tagged registry.test.example.com:5000/nodejs/nodejs-sample-app:latest

2f8b2441d5bb46d375a33ccc74122a55ea841425b6a5156d10c1e7176a91b920

[root@bastion 20230105_podman]#

0.2.1.5. Run the resulting image with the final application

podman run -d node-app

jboss-eap-7/eap74-openjdk8-runtime-openshift-rhel7

0.3. Network

0.3.1. hosts 

vi /etc/hosts

[root@lds203 ~]# tail -n 3 /etc/hosts

192.168.120.100 bgd-bgd.apps.test.example.com

192.168.120.100 bgd-bgdk.apps.test.example.com

192.168.120.100 guestbook.apps.test.example.com

192.168.120.100 helm-eap8-helm-eap8.apps.test.example.com

192.168.120.100 helm-nodejs-helm-nodejs.apps.test.example.com

[root@lds203 ~]#

0.4. Git 

0.4.1. Argo CD - Webhook

https://argo-cd.readthedocs.io/en/release-2.5/operator-manual/webhook/

https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/

https://argo-cd.readthedocs.io/en/release-2.5/operator-manual/applicationset/Generators-Git/#webhook-configuration

https://deploy.seldon.io/en/v1.2/contents/getting-started/production-installation/gitops.html

* Overview

   * Argo CD polls Git repositories every three minutes to detect changes to the manifests. To eliminate this delay from polling, the API server can be configured to receive webhook events. Argo CD supports Git webhook notifications from GitHub, GitLab, Bitbucket, Bitbucket Server and Gogs. The following explains how to configure a Git webhook for GitHub, but the same process should be applicable to other providers.

0.4.1.1. Create The WebHook In The Git Provider

In your Git provider, navigate to the settings page where webhooks can be configured. The payload URL configured in the Git provider should use the /api/webhook endpoint of your Argo CD instance (e.g. https://argocd.example.com/api/webhook). If you wish to use a shared secret, input an arbitrary value in the secret. This value will be used when configuring the webhook in the next step.

* Get the Route for the Argo CD/OpenShift GitOps server:

argoURL=$(oc get route openshift-gitops-server -n openshift-gitops -o jsonpath='{.spec.host}{"\n"}')

echo $argoURL

[root@bastion ~]# argoURL=$(oc get route openshift-gitops-server -n openshift-gitops -o jsonpath='{.spec.host}{"\n"}')

[root@bastion ~]# echo $argoURL

openshift-gitops-server-openshift-gitops.apps.test.example.com

[root@bastion ~]#

* Connect Gitlab

   * Login 

      * root

   * Admin Area > Settings > General > Network 

      * http://cicd.test.example.com/admin/application_settings/general

      * Outbound requests > Expand

         * Allow requests to the local network from web hooks and services : [Check]

* Connect Gitlab 

   * Note

      * Secret token 정보는 argo CD에서 정의된 값을 gitlab에 전달해 주는 형태

   * http://cicd.test.example.com

   * Project 

      * http://cicd.test.example.com/lds/openshift-gitops-examples.git

   * Projects > Settings > Webhooks

      * URL:

         * https://openshift-gitops-server-openshift-gitops.apps.test.example.com/api/webhook

         * Show full URL [Select]

      * Secret token: 

         * test

      * Trigger

         * Push events: [Check]

            * Wildcard pattern

               * main/*

               * branch 기준한 설정 적용

         * Tag push events: [Check]

            * Gitlab IDE에서 소스 수정시에는 동작 하지 않음 

            * Tag Event 기준으로 정상 동작

      * SSL verification

         * Enable SSL verification [Uncheck]

   * 추가 검토 사항 

      * url 정보는 gitlab server에 hosts로 등록되어 있어야 함 

      * container 사용시 해당 container에서도 hostalias로 등록되어 있어야 함 

0.4.1.2. Configure Argo CD With The WebHook Secret (Optional)

Configuring a webhook shared secret is optional, since Argo CD will still refresh applications related to the Git repository, even with unauthenticated webhook events. This is safe to do since the contents of webhook payloads are considered untrusted, and will only result in a refresh of the application (a process which already occurs at three-minute intervals). If Argo CD is publicly accessible, then configuring a webhook secret is recommended to prevent a DDoS attack.

In the argocd-secret kubernetes secret, configure one of the following keys with the Git provider's webhook secret configured in step 1.

* GitLab

   * webhook.gitlab.secret

* To encode secret content

   * https://linuxhint.com/bash_base64_encode_decode/

   * Secret token: 

      * test

echo -n 'test' | base64

echo dGVzdA== | base64 --decode