ArgoCD Tutorial - Getting Started II > OpenShift 자료실

본문 바로가기
사이트 내 전체검색

OpenShift 자료실

ArgoCD Tutorial - Getting Started II

페이지 정보

작성자 꿈꾸는여행자
댓글 0건 조회 186회 작성일 23-10-25 17:19




지난 내역과 계속하여 

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



   * 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: Pull a base builder image to build on

podman pull ubi8/nodejs-14

[root@bastion 20230105_podman]# pwd


[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

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


[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. Pull an application code

An example application available at is used here. Feel free to clone the repository for further experiments.

git clone app-src

[root@bastion 20230105_podman]# git clone 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]# 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. 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]# 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


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]# Build a new image from a Dockerfile prepared in the previous step

podman build -t node-app .

podman build -t \ .

podman push \

    --tls-verify=false \

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

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 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 <>.

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:

> 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 (

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


--> 2f8b2441d5b

Successfully tagged


[root@bastion 20230105_podman]# Run the resulting image with the final application

podman run -d node-app


0.3. Network

0.3.1. hosts 

vi /etc/hosts

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

[root@lds203 ~]#

0.4. Git 

0.4.1. Argo CD - Webhook

* 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. 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. 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='{}{"\n"}')

echo $argoURL

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

[root@bastion ~]# echo $argoURL

[root@bastion ~]#

* Connect Gitlab

   * Login 

      * root

   * Admin Area > Settings > General > Network 


      * Outbound requests > Expand

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

* Connect Gitlab 

   * Note

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


   * Project 


   * Projects > Settings > Webhooks

      * URL:


         * 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로 등록되어 있어야 함 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


   * Secret token: 

      * test

echo -n 'test' | base64

echo dGVzdA== | base64 --decode


등록된 댓글이 없습니다.



사이트 정보

회사명 : (주)리눅스데이타시스템 / 대표 : 정정모
서울본사 : 서울특별시 강남구 봉은사로 114길 40 홍선빌딩 2층 / tel : 02-6207-1160
대전지사 : 대전광역시 유성구 노은로174 도원프라자 5층 / tel : 042-331-1161


Copyright © All rights reserved.