이미지 사용

애플리케이션의ResourceOverride가 소스 디렉터리 /opt/openshift/src 에 중첩된 경우 고유한 . dpdk 파일을 지정하여 기본 Apache 동작을 재정의하고 애플리케이션 요청을 처리하는 방법을 지정할 수 있습니다. .dpdk 파일은 애플리케이션 소스의 루트에 있어야 합니다.

공유 볼륨을 처음 사용하면 데이터베이스 관리자 사용자 및 MySQL 루트 사용자와 함께 데이터베이스가 생성됩니다(tekton _ROOT_PASSWORD 환경 변수를 지정하는 경우). 그런 다음 MySQL 데몬이 시작됩니다. 볼륨을 다른 컨테이너에 다시 연결하는 경우 데이터베이스, 데이터베이스 사용자 및 관리자 사용자가 생성되지 않으며 MySQL 데몬이 시작됩니다.

다음 명령은 컨테이너에서 MySQL이 실행되는 새 데이터베이스 포드 를 생성합니다.

$ oc new-app \
    -e MYSQL_USER=<username> \
    -e MYSQL_PASSWORD=<password> \
    -e MYSQL_DATABASE=<database_name> \
    registry.redhat.io/rhscl/mysql-56-rhel7

OpenShift Container Platform은 소프트웨어 컬렉션 (SCL)을 사용하여 MySQL을 설치하고 시작합니다. 실행 중인 컨테이너 내부에서 MySQL 명령을 실행하려면( 디버깅용) bash를 사용하여 호출해야 합니다.

이렇게 하려면 먼저 Pod 이름을 확인합니다. 예를 들어 현재 프로젝트의 Pod 목록을 볼 수 있습니다.

$ oc get pods

그런 다음 Pod에 대한 원격 쉘 세션을 엽니다.

$ oc rsh <pod>

컨테이너를 입력하면 필요한 SCL이 자동으로 활성화됩니다.

이제 bash 쉘에서 mysql 명령을 실행하여 MySQL 대화형 세션을 시작하고 일반 MySQL 작업을 수행할 수 있습니다. 예를 들어 데이터베이스 사용자로 인증하려면 다음을 수행합니다.

bash-4.2$ mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -h $HOSTNAME $MYSQL_DATABASE
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.6.37 MySQL Community Server (GPL)
...
mysql>

완료되면 exit 또는 exit를 입력하여 MySQL 세션을 종료합니다.

MySQL 사용자 이름, 암호 및 데이터베이스 이름은 다음 환경 변수를 사용하여 구성해야 합니다.

MySQL 설정은 다음 환경 변수로 구성할 수 있습니다.

일부 메모리 관련 매개 변수에는 두 가지 기본값이 있습니다. 고정된 값은 컨테이너에 메모리 제한이 할당되지 않은 경우 사용됩니다. 다른 값은 사용 가능한 메모리를 기반으로 컨테이너 시작 중에 동적으로 계산됩니다.

MySQL 이미지는 데이터베이스의 영구 스토리지를 활성화하기 위해 마운트된 볼륨을 사용하여 실행할 수 있습니다.

암호는 이미지 구성의 일부이므로 데이터베이스 사용자(tekton_USER) 및 root 사용자의 암호를 변경하기 위해 지원되는 유일한 방법은 환경 변수tekton _PASSWORD 및tekton_ ROOT_PASSWORD 를 각각 변경하는 것입니다.

웹 콘솔에서 Pod 또는 배포 구성을 보거나 CLI로 환경 변수를 나열하여 현재 암호를 볼 수 있습니다.

$ oc set env pod <pod_name> --list

jenkinsfile _ROOT_PASSWORD 가 설정될 때마다 지정된 암호를 사용하여 root 사용자에 대한 원격 액세스를 활성화하고 설정되지 않은 경우 root 사용자에 대한 원격 액세스가 비활성화됩니다. 이는 항상 원격 액세스 권한이 있는 일반 사용자ECDHE_USER 에는 영향을 미치지 않습니다. 또한 localhost 에서 암호 없이 로그인할 수 있는 root 사용자의 로컬 액세스에도 영향을 미치지 않습니다.

SQL 문을 통해 데이터베이스 암호를 변경하거나 앞서 언급한 환경 변수를 제외한 다른 방식으로 데이터베이스 암호를 변경하면 변수에 저장된 값과 실제 암호가 일치하지 않습니다. 데이터베이스 컨테이너가 시작될 때마다 환경 변수에 저장된 값으로 암호를 재설정합니다.

이러한 암호를 변경하려면 oc set env 명령을 사용하여 관련 배포 구성에 대해 원하는 환경 변수를 하나 또는 둘 다 업데이트합니다. 여러 배포 구성에서 이러한 환경 변수를 활용하는 경우 예를 들어 템플릿에서 생성된 애플리케이션의 경우 암호가 모든 위치에서 동기화되도록 각 배포 구성에서 변수를 업데이트해야 합니다. 이 작업은 모두 동일한 명령에서 수행할 수 있습니다.

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  MYSQL_PASSWORD=<new_password> \
  MYSQL_ROOT_PASSWORD=<new_root_password>

환경 변수를 업데이트하면 구성 변경 트리거 가 있는 경우 데이터베이스 서버의 재배포가 트리거됩니다. 그러지 않으면 암호 변경 사항을 적용하려면 새 배포를 수동으로 시작해야 합니다.

새 암호가 적용되었는지 확인하려면 먼저 실행 중인 MySQL 포드에 대한 원격 쉘 세션을 엽니다.

$ oc rsh <pod>

bash 쉘에서 데이터베이스 사용자의 새 암호를 확인합니다.

bash-4.2$ mysql -u $MYSQL_USER -p<new_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

암호가 올바르게 변경된 경우 다음과 같은 테이블이 표시됩니다.

+------------+---------------------+
| database() | user()              |
+------------+---------------------+
| sampledb   | user0PG@172.17.42.1 |
+------------+---------------------+

root 사용자의 새 암호를 확인하려면 다음을 수행하십시오.

bash-4.2$ mysql -u root -p<new_root_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

암호가 올바르게 변경된 경우 다음과 같은 테이블이 표시됩니다.

+------------+------------------+
| database() | user()           |
+------------+------------------+
| sampledb   | root@172.17.42.1 |
+------------+------------------+

MySQL 복제를 설정하기 위해 배포 구성 은 예제 템플릿에 정의되어 복제 컨트롤러를 정의합니다. MySQL 마스터-슬레이브 복제의 경우 두 개의 배포 구성이 필요합니다. 하나의 배포 구성은 MySQL 마스터 서버 및 MySQL 슬레이브 서버를 정의합니다.

MySQL 서버가 마스터 역할을 하도록 지시하려면 배포 구성의 컨테이너 정의의 command 필드가 run-mysqld-master 로 설정되어야 합니다. 이 스크립트는 MySQL 이미지의 대체 진입점 역할을 하며 복제에서 마스터로 실행되도록 MySQL 서버를 구성합니다.

MySQL 복제에는 마스터와 슬레이브 간에 데이터를 릴레이하는 특수 사용자가 필요합니다. 이 목적으로 템플릿에 다음 환경 변수가 정의됩니다.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "mysql-master"
spec:
  strategy:
    type: "Recreate"
  triggers:
    - type: "ConfigChange"
  replicas: 1
  selector:
    name: "mysql-master"
  template:
    metadata:
      labels:
        name: "mysql-master"
    spec:
      volumes:
        - name: "mysql-master-data"
          persistentVolumeClaim:
            claimName: "mysql-master"
      containers:
        - name: "server"
          image: "openshift/mysql-56-centos7"
          command:
            - "run-mysqld-master"
          ports:
            - containerPort: 3306
              protocol: "TCP"
          env:
            - name: "MYSQL_MASTER_USER"
              value: "${MYSQL_MASTER_USER}"
            - name: "MYSQL_MASTER_PASSWORD"
              value: "${MYSQL_MASTER_PASSWORD}"
            - name: "MYSQL_USER"
              value: "${MYSQL_USER}"
            - name: "MYSQL_PASSWORD"
              value: "${MYSQL_PASSWORD}"
            - name: "MYSQL_DATABASE"
              value: "${MYSQL_DATABASE}"
            - name: "MYSQL_ROOT_PASSWORD"
              value: "${MYSQL_ROOT_PASSWORD}"
          volumeMounts:
            - name: "mysql-master-data"
              mountPath: "/var/lib/mysql/data"
          resources: {}
          terminationMessagePath: "/dev/termination-log"
          imagePullPolicy: "IfNotPresent"
          securityContext:
            capabilities: {}
            privileged: false
      restartPolicy: "Always"
      dnsPolicy: "ClusterFirst"

이 배포 구성에서 모든 데이터가 MySQL 마스터 서버에 대해 지속되도록 영구 볼륨을 요청했기 때문에 클러스터 관리자에게 스토리지를 클레임할 수 있는 영구 볼륨을 생성하도록 요청해야 합니다.

배포 구성이 생성되고 MySQL 마스터 서버를 사용하는 포드가 started되면 sysfs _DATABASE 에서 정의한 데이터베이스를 생성하고 이 데이터베이스를 슬레이브로 복제하도록 서버를 구성합니다.

제공된 예제에서는 MySQL 마스터 서버의 복제본을 하나만 정의합니다. 이로 인해 OpenShift Container Platform에서 서버 인스턴스가 하나만 시작됩니다. 다중 인스턴스(multi-master)는 지원되지 않으므로 이 복제 컨트롤러를 확장할 수 없습니다.

MySQL 마스터 에서 생성한 데이터베이스를 복제하기 위해 템플릿에 배포 구성이 정의됩니다. 이 배포 구성은 run-mysqld-slave 로 설정된 command 필드를 사용하여 MySQL 이미지를 시작하는 복제 컨트롤러를 생성합니다. 이 대체 진입점은 데이터베이스 초기화를 건너뛰고 예제 템플릿에도 정의되어 있는 mysql-master 서비스에 연결하도록 MySQL 서버를 구성합니다.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "mysql-slave"
spec:
  strategy:
    type: "Recreate"
  triggers:
    - type: "ConfigChange"
  replicas: 1
  selector:
    name: "mysql-slave"
  template:
    metadata:
      labels:
        name: "mysql-slave"
    spec:
      containers:
        - name: "server"
          image: "openshift/mysql-56-centos7"
          command:
            - "run-mysqld-slave"
          ports:
            - containerPort: 3306
              protocol: "TCP"
          env:
            - name: "MYSQL_MASTER_USER"
              value: "${MYSQL_MASTER_USER}"
            - name: "MYSQL_MASTER_PASSWORD"
              value: "${MYSQL_MASTER_PASSWORD}"
            - name: "MYSQL_DATABASE"
              value: "${MYSQL_DATABASE}"
          resources: {}
          terminationMessagePath: "/dev/termination-log"
          imagePullPolicy: "IfNotPresent"
          securityContext:
            capabilities: {}
            privileged: false
      restartPolicy: "Always"
      dnsPolicy: "ClusterFirst"

이 예제 배포 구성은 초기 복제본 수가 1 로 설정된 복제 컨트롤러를 시작합니다. 이 복제 컨트롤러는 계정의 리소스 용량까지 두 방향 모두에서 확장 할 수 있습니다.

MySQL 슬레이브 복제 컨트롤러에서 생성한 포드는 복제를 등록하려면 MySQL 마스터 서버에 도달해야 합니다. 예제 템플릿은 이러한 목적으로 mysql-master 라는 헤드리스 서비스를 정의합니다. 이 서비스는 복제에만 사용되지 않지만 클라이언트는 MySQL 호스트로 쿼리를 mysql-master:3306 에 보낼 수도 있습니다.

헤드리스 서비스를 사용하려면 서비스 정의의 clusterIP 매개 변수가 None 으로 설정됩니다. 그러면 DNS 쿼리를 사용하여 이 서비스의 현재 끝점을 나타내는 Pod IP 주소 목록을 가져올 수 있습니다.

kind: "Service"
apiVersion: "v1"
metadata:
  name: "mysql-master"
  labels:
    name: "mysql-master"
spec:
  ports:
    - protocol: "TCP"
      port: 3306
      targetPort: 3306
      nodePort: 0
  selector:
    name: "mysql-master"
  clusterIP: "None"
  type: "ClusterIP"
  sessionAffinity: "None"
status:
  loadBalancer: {}

클러스터 의 구성원 수를 늘리려면 다음을 수행합니다.

$ oc scale rc mysql-slave-1 --replicas=<number>

복제 컨트롤러에서 새 MySQL 슬레이브 포드를 생성하도록 지시합니다. 새 슬레이브가 생성되면 먼저 슬레이브 엔트리 포인트가 mysql-master 서비스에 연결을 시도하고 복제 세트에 자신을 등록합니다. 이 작업이 완료되면 MySQL 마스터 서버에서 복제된 데이터베이스에 슬레이브를 보냅니다.

축소하면 MySQL 슬레이브가 종료되고 슬레이브에 영구 스토리지가 정의되어 있지 않기 때문에 슬레이브의 모든 데이터가 손실됩니다. 그런 다음 MySQL 마스터 서버는 슬레이브에 더 이상 연결할 수 없음을 검색하고 복제에서 자동으로 해당 슬레이브를 제거합니다.

151113  5:06:56 InnoDB: Using Linux native AIO
151113  5:06:56  InnoDB: Warning: io_setup() failed with EAGAIN. Will make 5 attempts before giving up.
InnoDB: Warning: io_setup() attempt 1 failed.
InnoDB: Warning: io_setup() attempt 2 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 3 failed.
InnoDB: Warning: io_setup() attempt 4 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 5 failed.
151113  5:06:59  InnoDB: Error: io_setup() failed with EAGAIN after 5 attempts.
InnoDB: You can disable Linux Native AIO by setting innodb_use_native_aio = 0 in my.cnf
151113  5:06:59 InnoDB: Fatal error: cannot initialize AIO sub-system
151113  5:06:59 [ERROR] Plugin 'InnoDB' init function returned error.
151113  5:06:59 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151113  5:06:59 [ERROR] Unknown/unsupported storage engine: InnoDB
151113  5:06:59 [ERROR] Aborting

또는 aio-max-nr 커널 리소스를 늘립니다. 다음 예제에서는 aio-max-nr 의 현재 값을 검사하고 두 번 실행합니다.

$ sysctl fs.aio-max-nr
fs.aio-max-nr = 1048576
# sysctl -w fs.aio-max-nr=2097152

노드별 확인이며 다음 노드를 재부팅할 때까지 지속됩니다.

공유 볼륨을 처음 사용하면 데이터베이스 관리자 및 PostgreSQL postgres 사용자와 함께 데이터베이스가 생성됩니다( POSTGRESQL_ADMIN_PASSWORD 환경 변수를 지정하는 경우). PostgreSQL 데몬이 시작됩니다. 볼륨을 다른 컨테이너에 다시 연결하는 경우 데이터베이스, 데이터베이스 사용자 및 관리자 사용자가 생성되지 않으며 PostgreSQL 데몬이 시작됩니다.

다음 명령은 컨테이너에서 PostgreSQL이 실행되는 새 데이터베이스 포드 를 생성합니다.

$ oc new-app \
    -e POSTGRESQL_USER=<username> \
    -e POSTGRESQL_PASSWORD=<password> \
    -e POSTGRESQL_DATABASE=<database_name> \
    registry.redhat.io/rhscl/postgresql-95-rhel7

OpenShift Container Platform은 소프트웨어 컬렉션 (SCL)을 사용하여 PostgreSQL을 설치하고 시작합니다. 실행 중인 컨테이너 내부에서 PostgreSQL 명령을 실행하려면( 디버깅용) bash를 사용하여 호출해야 합니다.

이렇게 하려면 먼저 실행 중인 PostgreSQL 포드의 이름을 확인합니다. 예를 들어 현재 프로젝트의 Pod 목록을 볼 수 있습니다.

$ oc get pods

그런 다음 원격 쉘 세션을 원하는 Pod로 엽니다.

$ oc rsh <pod>

컨테이너를 입력하면 필요한 SCL이 자동으로 활성화됩니다.

이제 bash 쉘에서 psql 명령을 실행하여 PostgreSQL 대화형 세션을 시작하고 일반 PostgreSQL 작업을 수행할 수 있습니다. 예를 들어 데이터베이스 사용자로 인증하려면 다음을 수행합니다.

bash-4.2$ PGPASSWORD=$POSTGRESQL_PASSWORD psql -h postgresql $POSTGRESQL_DATABASE $POSTGRESQL_USER
psql (9.5.16)
Type "help" for help.

default=>

완료되면 \q 를 입력하여 PostgreSQL 세션을 종료합니다.

PostgreSQL 사용자 이름, 암호 및 데이터베이스 이름은 다음 환경 변수를 사용하여 구성해야 합니다.

PostgreSQL 설정은 다음 환경 변수로 구성할 수 있습니다.

PostgreSQL 이미지는 데이터베이스의 영구 스토리지를 활성화하기 위해 마운트된 볼륨을 사용하여 실행할 수 있습니다.

암호는 이미지 구성의 일부이므로 데이터베이스 사용자(POSTGRESQL_USER) 및 postgres 관리자 사용자의 암호를 변경하는 데 지원되는 유일한 방법은 환경 변수 POSTGRESQL_PASSWORD 및 POSTGRESQL_ADMIN_PASSWORD 를 각각 변경하는 것입니다.

웹 콘솔에서 Pod 또는 배포 구성을 보거나 CLI로 환경 변수를 나열하여 현재 암호를 볼 수 있습니다.

$ oc set env pod <pod_name> --list

SQL 문을 통해 데이터베이스 암호를 변경하거나 앞서 언급한 환경 변수를 제외한 다른 방식으로 데이터베이스 암호를 변경하면 변수에 저장된 값과 실제 암호가 일치하지 않습니다. 데이터베이스 컨테이너가 시작될 때마다 환경 변수에 저장된 값으로 암호를 재설정합니다.

이러한 암호를 변경하려면 oc set env 명령을 사용하여 관련 배포 구성에 대해 원하는 환경 변수를 하나 또는 둘 다 업데이트합니다. 여러 배포 구성에서 이러한 환경 변수를 활용하는 경우 예를 들어 템플릿에서 생성된 애플리케이션의 경우 암호가 모든 위치에서 동기화되도록 각 배포 구성에서 변수를 업데이트해야 합니다. 이 작업은 모두 동일한 명령에서 수행할 수 있습니다.

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  POSTGRESQL_PASSWORD=<new_password> \
  POSTGRESQL_ADMIN_PASSWORD=<new_admin_password>

환경 변수를 업데이트하면 구성 변경 트리거 가 있는 경우 데이터베이스 서버의 재배포가 트리거됩니다. 그러지 않으면 암호 변경 사항을 적용하려면 새 배포를 수동으로 시작해야 합니다.

새 암호가 적용되었는지 확인하려면 먼저 실행 중인 PostgreSQL 포드에 대한 원격 쉘 세션을 엽니다.

$ oc rsh <pod>

bash 쉘에서 데이터베이스 사용자의 새 암호를 확인합니다.

bash-4.2$ PGPASSWORD=<new_password> psql -h postgresql $POSTGRESQL_DATABASE $POSTGRESQL_USER -c "SELECT * FROM (SELECT current_database()) cdb CROSS JOIN (SELECT current_user) cu"

암호가 올바르게 변경된 경우 다음과 같은 테이블이 표시됩니다.

 current_database | current_user
------------------+--------------
 default          | django
(1 row)

bash 쉘에서 postgres 관리자의 새 암호를 확인합니다.

bash-4.2$ PGPASSWORD=<new_admin_password> psql -h postgresql $POSTGRESQL_DATABASE postgres -c "SELECT * FROM (SELECT current_database()) cdb CROSS JOIN (SELECT current_user) cu"

암호가 올바르게 변경된 경우 다음과 같은 테이블이 표시됩니다.

 current_database | current_user
------------------+--------------
 default          | postgres
(1 row)

임시 볼륨 또는 영구 볼륨을 사용하여 MongoDB를 구성할 수 있습니다. 처음 볼륨을 사용하면 데이터베이스 관리자와 함께 데이터베이스가 생성됩니다. 그런 다음 MongoDB 데몬이 시작됩니다. 볼륨을 다른 컨테이너에 다시 연결하는 경우 데이터베이스, 데이터베이스 사용자 및 관리자 사용자가 생성되지 않고 MongoDB 데몬이 시작됩니다.

다음 명령은 임시 볼륨이 있는 컨테이너에서 MongoDB가 실행되고 있는 새 데이터베이스 포드 를 생성합니다.

$ oc new-app \
    -e MONGODB_USER=<username> \
    -e MONGODB_PASSWORD=<password> \
    -e MONGODB_DATABASE=<database_name> \
    -e MONGODB_ADMIN_PASSWORD=<admin_password> \
    registry.redhat.io/rhscl/mongodb-26-rhel7

OpenShift Container Platform은 소프트웨어 컬렉션 (SCL)을 사용하여 MongoDB를 설치하고 시작합니다. 실행 중인 컨테이너 내부에서 MongoDB 명령을 실행하려면( 디버깅용) bash를 사용하여 호출해야 합니다.

이렇게 하려면 먼저 실행 중인 MongoDB 포드의 이름을 확인합니다. 예를 들어 현재 프로젝트의 Pod 목록을 볼 수 있습니다.

$ oc get pods

그런 다음 원격 쉘 세션을 원하는 Pod로 엽니다.

$ oc rsh <pod>

컨테이너를 입력하면 필요한 SCL이 자동으로 활성화됩니다.

이제 bash 쉘에서 mongo 명령을 실행하여 MongoDB 대화형 세션을 시작하고 일반 MongoDB 작업을 수행할 수 있습니다. 예를 들어 sampledb 데이터베이스로 전환하고 데이터베이스 사용자로 인증하려면 다음을 수행합니다.

bash-4.2$ mongo -u $MONGODB_USER -p $MONGODB_PASSWORD $MONGODB_DATABASE
MongoDB shell version: 2.6.9
connecting to: sampledb
>

완료되면 CTRL+D 를 눌러 MongoDB 세션을 종료합니다.

MongoDB 사용자 이름, 암호, 데이터베이스 이름 및 관리자 암호는 다음 환경 변수를 사용하여 구성해야 합니다.

MongoDB 설정은 다음 환경 변수로 구성할 수 있습니다.

데이터베이스의 영구 스토리지를 활성화하기 위해 마운트된 볼륨을 사용하여 MongoDB 이미지를 실행할 수 있습니다.

암호는 이미지 구성의 일부이므로 데이터베이스 사용자(MONGODB_USER)의 암호를 변경하기 위해 지원되는 유일한 방법 및 admin 사용자는 환경 변수 MONGODB_PASSWORD 및 MONGODB_ADMIN_PASSWORD 를 각각 변경하는 것입니다.

웹 콘솔에서 Pod 또는 배포 구성을 보거나 CLI로 환경 변수를 나열하여 현재 암호를 볼 수 있습니다.

$ oc set env pod <pod_name> --list

MongoDB에서 직접 데이터베이스 암호를 변경하면 변수에 저장된 값과 실제 암호가 일치하지 않습니다. 데이터베이스 컨테이너가 시작될 때마다 환경 변수에 저장된 값으로 암호를 재설정합니다.

이러한 암호를 변경하려면 oc set env 명령을 사용하여 관련 배포 구성에 대해 원하는 환경 변수를 하나 또는 둘 다 업데이트합니다. 여러 배포 구성에서 이러한 환경 변수를 활용하는 경우 예를 들어 템플릿에서 생성된 애플리케이션의 경우 암호가 모든 위치에서 동기화되도록 각 배포 구성에서 변수를 업데이트해야 합니다. 이 작업은 모두 동일한 명령에서 수행할 수 있습니다.

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  MONGODB_PASSWORD=<new_password> \
  MONGODB_ADMIN_PASSWORD=<new_admin_password>

환경 변수를 업데이트하면 구성 변경 트리거 가 있는 경우 데이터베이스 서버의 재배포가 트리거됩니다. 그러지 않으면 암호 변경 사항을 적용하려면 새 배포를 수동으로 시작해야 합니다.

새 암호가 적용되었는지 확인하려면 먼저 실행 중인 MongoDB 포드에 원격 쉘 세션을 엽니다.

$ oc rsh <pod>

bash 쉘에서 데이터베이스 사용자의 새 암호를 확인합니다.

bash-4.2$ mongo -u $MONGODB_USER -p <new_password> $MONGODB_DATABASE --eval "db.version()"

암호가 올바르게 변경된 경우 다음과 같은 출력이 표시됩니다.

MongoDB shell version: 2.6.9
connecting to: sampledb
2.6.9

admin 사용자의 새 암호를 확인하려면 다음을 수행하십시오.

bash-4.2$ mongo -u admin -p <new_admin_password> admin --eval "db.version()"

암호가 올바르게 변경된 경우 다음과 같은 출력이 표시됩니다.

MongoDB shell version: 2.6.9
connecting to: admin
2.6.9

이미 세 개의 영구 볼륨이 있거나 영구 볼륨 프로비저닝을 구성했다고 가정합니다.

예제 템플릿에서 클러스터를 생성한 후 세 개의 멤버가 있는 복제본 세트가 있습니다. Pod가 실행되면 다음과 같은 Pod에서 다양한 작업을 수행할 수 있습니다.

MongoDB는 복제본 세트의 홀수의 멤버를 권장합니다. 사용 가능한 영구 볼륨이 충분하거나 동적 스토리지 프로비저너가 있는 경우 oc scale 명령을 사용하여 확장합니다.

$ oc scale --replicas=5 statefulsets/mongodb

$ oc get pods
NAME        READY     STATUS    RESTARTS   AGE
mongodb-0   1/1       Running   0          9m
mongodb-1   1/1       Running   0          8m
mongodb-2   1/1       Running   0          8m
mongodb-3   1/1       Running   0          1m
mongodb-4   1/1       Running   0          57s

이렇게 하면 복제본 세트에 연결하고 해당 구성을 업데이트하는 새 포드가 생성됩니다.

복제본 세트를 축소하려면 5개의 멤버 또는 3개의 멤버에서 하나의 멤버로만 이동할 수 있습니다.

사전 조건이 충족된 경우 수동 개입 없이 확장(스토리지 가용성, 기존 데이터베이스 및 oplogSize) 축소에 항상 수동 개입이 필요할 수 있습니다.

축소하려면 다음을 수행합니다.

공유 볼륨을 처음 사용하면 데이터베이스 관리자 사용자 및 MariaDB 루트 사용자와 함께 데이터베이스가 생성됩니다(tekton _ROOT_PASSWORD 환경 변수를 지정하는 경우). 그런 다음 MariaDB 데몬이 시작됩니다. 볼륨을 다른 컨테이너에 다시 연결하는 경우 데이터베이스, 데이터베이스 사용자 및 관리자 사용자가 생성되지 않고 MariaDB 데몬이 시작됩니다.

다음 명령은 컨테이너에서 MariaDB가 실행되는 새 데이터베이스 포드 를 생성합니다.

$ oc new-app \
    -e MYSQL_USER=<username> \
    -e MYSQL_PASSWORD=<password> \
    -e MYSQL_DATABASE=<database_name> \
    registry.redhat.io/rhscl/mariadb-101-rhel7

OpenShift Container Platform은 소프트웨어 컬렉션 (SCL)을 사용하여 MariaDB를 설치하고 시작합니다. 실행 중인 컨테이너 내부에서 MariaDB 명령을 실행하려면( 디버깅용) bash를 사용하여 호출해야 합니다.

이렇게 하려면 먼저 실행 중인 MariaDB 포드의 이름을 확인합니다. 예를 들어 현재 프로젝트의 Pod 목록을 볼 수 있습니다.

$ oc get pods

그런 다음 Pod에 대한 원격 쉘 세션을 엽니다.

$ oc rsh <pod>

컨테이너를 입력하면 필요한 SCL이 자동으로 활성화됩니다.

이제 bash 쉘에서 mysql 명령을 실행하여 MariaDB 대화형 세션을 시작하고 일반 MariaDB 작업을 수행할 수 있습니다. 예를 들어 데이터베이스 사용자로 인증하려면 다음을 수행합니다.

bash-4.2$ mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -h $HOSTNAME $MYSQL_DATABASE
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.5.37 MySQL Community Server (GPL)
...
mysql>

완료되면 exit 또는 exit를 입력하여 MySQL 세션을 종료합니다.

MariaDB 사용자 이름, 암호 및 데이터베이스 이름은 다음 환경 변수를 사용하여 구성해야 합니다.

MariaDB 설정은 다음 환경 변수로 구성할 수 있습니다.

MariaDB 이미지는 데이터베이스의 영구 스토리지를 활성화하기 위해 마운트된 볼륨을 사용하여 실행할 수 있습니다.

암호는 이미지 구성의 일부이므로 데이터베이스 사용자(tekton_USER) 및 admin 사용자의 암호를 변경하는 데 지원되는 유일한 방법은 환경 변수tekton _PASSWORD 및tekton_ ROOT_PASSWORD 를 각각 변경하는 것입니다.

웹 콘솔에서 Pod 또는 배포 구성을 보거나 CLI로 환경 변수를 나열하여 현재 암호를 볼 수 있습니다.

$ oc set env pod <pod_name> --list

SQL 문을 통해 데이터베이스 암호를 변경하거나 앞서 언급한 환경 변수를 제외한 다른 방식으로 데이터베이스 암호를 변경하면 변수에 저장된 값과 실제 암호가 일치하지 않습니다. 데이터베이스 컨테이너가 시작될 때마다 환경 변수에 저장된 값으로 암호를 재설정합니다.

이러한 암호를 변경하려면 oc set env 명령을 사용하여 관련 배포 구성에 대해 원하는 환경 변수를 하나 또는 둘 다 업데이트합니다. 여러 배포 구성에서 이러한 환경 변수를 활용하는 경우 예를 들어 템플릿에서 생성된 애플리케이션의 경우 암호가 모든 위치에서 동기화되도록 각 배포 구성에서 변수를 업데이트해야 합니다. 이 작업은 모두 동일한 명령에서 수행할 수 있습니다.

$ oc set env dc <dc_name> [<dc_name_2> ...] \
  MYSQL_PASSWORD=<new_password> \
  MYSQL_ROOT_PASSWORD=<new_root_password>

환경 변수를 업데이트하면 구성 변경 트리거 가 있는 경우 데이터베이스 서버의 재배포가 트리거됩니다. 그러지 않으면 암호 변경 사항을 적용하려면 새 배포를 수동으로 시작해야 합니다.

새 암호가 적용되었는지 확인하려면 먼저 실행 중인 MariaDB 포드에 원격 쉘 세션을 엽니다.

$ oc rsh <pod>

bash 쉘에서 데이터베이스 사용자의 새 암호를 확인합니다.

bash-4.2$ mysql -u $MYSQL_USER -p<new_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

암호가 올바르게 변경된 경우 다음과 같은 테이블이 표시됩니다.

+------------+---------------------+
| database() | user()              |
+------------+---------------------+
| sampledb   | user0PG@172.17.42.1 |
+------------+---------------------+

root 사용자의 새 암호를 확인하려면 다음을 수행하십시오.

bash-4.2$ mysql -u root -p<new_root_password> -h $HOSTNAME $MYSQL_DATABASE -te "SELECT * FROM (SELECT database()) db CROSS JOIN (SELECT user()) u"

암호가 올바르게 변경된 경우 다음과 같은 테이블이 표시됩니다.

+------------+------------------+
| database() | user()           |
+------------+------------------+
| sampledb   | root@172.17.42.1 |
+------------+------------------+

151113  5:06:56 InnoDB: Using Linux native AIO
151113  5:06:56  InnoDB: Warning: io_setup() failed with EAGAIN. Will make 5 attempts before giving up.
InnoDB: Warning: io_setup() attempt 1 failed.
InnoDB: Warning: io_setup() attempt 2 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 3 failed.
InnoDB: Warning: io_setup() attempt 4 failed.
Waiting for MySQL to start ...
InnoDB: Warning: io_setup() attempt 5 failed.
151113  5:06:59  InnoDB: Error: io_setup() failed with EAGAIN after 5 attempts.
InnoDB: You can disable Linux Native AIO by setting innodb_use_native_aio = 0 in my.cnf
151113  5:06:59 InnoDB: Fatal error: cannot initialize AIO sub-system
151113  5:06:59 [ERROR] Plugin 'InnoDB' init function returned error.
151113  5:06:59 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151113  5:06:59 [ERROR] Unknown/unsupported storage engine: InnoDB
151113  5:06:59 [ERROR] Aborting

또는 aio-max-nr 커널 리소스를 늘립니다. 다음 예제에서는 aio-max-nr 의 현재 값을 검사하고 두 번 실행합니다.

$ sysctl fs.aio-max-nr
fs.aio-max-nr = 1048576
# sysctl -w fs.aio-max-nr=2097152

노드별 확인이며 다음 노드를 재부팅할 때까지 지속됩니다.

Jenkins 인증은 다음 두 가지 방법으로 관리할 수 있습니다.

$ oc new-app -e \
    JENKINS_PASSWORD=<password> \
    openshift/jenkins-2-centos7

Jenkins 서버는 다음 환경 변수로 구성할 수 있습니다.

동일한 프로젝트에서 배포가 아닌 다른 위치에서 Jenkins를 실행하려는 경우 Jenkins에 액세스 토큰을 제공하여 프로젝트에 액세스해야 합니다.

토큰 필드에는 Jenkins가 프로젝트에 액세스하는 데 필요한 토큰 값이 포함되어 있습니다.

구성을 위한 영구 스토리지가 활성화되도록 마운트된 볼륨을 사용하여 Jenkins 이미지를 실행할 수 있습니다.

공식 OpenShift Container Platform Jenkins 이미지를 사용자 정의하려면 다음 두 가지 옵션이 있습니다.

S2I 를 사용하여 사용자 정의 Jenkins 작업 정의, 추가 플러그인 또는 제공된 config.xml 파일을 자체 사용자 정의 구성으로 교체할 수 있습니다.

Jenkins 이미지에 수정 사항을 포함하려면 다음 디렉터리 구조를 사용하는 Git 리포지토리가 있어야 합니다.

pluginId:pluginVersion

configuration/ 디렉토리의 내용은 /var/lib/jenkins/ 디렉토리에 복사되므로 credentials.xml 와 같은 추가 파일을 포함할 수도 있습니다.

다음은 OpenShift Container Platform의 Jenkins 이미지를 사용자 지정하는 빌드 구성의 예입니다.

apiVersion: v1
kind: BuildConfig
metadata:
  name: custom-jenkins-build
spec:
  source:                       1
    git:
      uri: https://github.com/custom/repository
    type: Git
  strategy:                     2
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: jenkins:latest
        namespace: openshift
    type: Source
  output:                       3
    to:
      kind: ImageStreamTag
      name: custom-jenkins:latest

OpenShift Container Platform Jenkins 이미지에는 Kubernetes 및 OpenShift Container Platform을 사용하여 여러 컨테이너 호스트에서 Jenkins 에이전트를 동적으로 프로비저닝할 수 있는 사전 설치된 Kubernetes 플러그인이 포함되어 있습니다.

Kubernetes 플러그인을 사용하도록 OpenShift Container Platform은 Jenkins 에이전트로 사용하기에 적합한 5개의 이미지( 기본, Maven, Node.js )를 제공합니다. 자세한 내용은 Jenkins 에이전트 를 참조하십시오.

Maven 및 Node.js 에이전트 이미지 둘 다 OpenShift Container Platform Jenkins 이미지의 쿠버네티스 플러그인 구성에서 쿠버네티스 포드 템플릿 이미지로 자동 구성됩니다. 해당 구성에는 "이 프로젝트를 실행할 수 있는" 설정에 따라 모든 Jenkins 작업에 적용할 수 있는 각 이미지의 레이블이 포함됩니다. 레이블이 적용되면 해당 에이전트 이미지를 실행하는 OpenShift Container Platform Pod에서 지정된 작업 실행이 수행됩니다.

Jenkins 이미지는 Kubernetes 플러그인의 추가 에이전트 이미지 자동 검색 및 자동 구성 기능도 제공합니다. OpenShift 동기화 플러그인 을 사용하면 Jenkins 시작 시 Jenkins 이미지가 실행 중인 프로젝트 또는 플러그인 구성에 구체적으로 나열된 프로젝트에서 다음을 검색합니다.

적절한 레이블이 있는 이미지 스트림 또는 적절한 주석이 있는 이미지 스트림 태그를 찾으면 해당 Kubernetes 플러그인 구성이 생성되므로 이미지 스트림에서 제공하는 컨테이너 이미지를 실행하는 포드에서 Jenkins 작업을 실행하도록 할당할 수 있습니다.

이미지 스트림 또는 이미지 스트림 태그의 이름 및 이미지 참조는 Kubernetes 플러그인 pod 템플릿의 이름 및 이미지 필드에 매핑됩니다. slave-label 키로 이미지 스트림 또는 이미지 스트림 태그 오브젝트에 주석을 설정하여 Kubernetes 플러그인 pod 템플릿의 레이블 필드를 제어할 수 있습니다. 그러지 않으면 이름이 레이블로 사용됩니다.

적절한 레이블이 있는 ConfigMap을 찾으면 ConfigMap의 키-값 데이터 페이로드에 있는 값에 Jenkins 및 Kubernetes 플러그인 pod 템플릿의 구성 형식과 일치하는 XML이 포함되어 있다고 가정합니다. 이미지 스트림 또는 이미지 스트림 태그 대신 ConfigMap을 사용할 때 유의해야 할 중요한 차이점은 Kubernetes 플러그인 pod 템플릿의 모든 다양한 필드를 제어할 수 있다는 것입니다.

다음은 예제 ConfigMap입니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-slave
data:
  template1: |-
    <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
      <inheritFrom></inheritFrom>
      <name>template1</name>
      <instanceCap>2147483647</instanceCap>
      <idleMinutes>0</idleMinutes>
      <label>template1</label>
      <serviceAccount>jenkins</serviceAccount>
      <nodeSelector></nodeSelector>
      <volumes/>
      <containers>
        <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          <name>jnlp</name>
          <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image>
          <privileged>false</privileged>
          <alwaysPullImage>true</alwaysPullImage>
          <workingDir>/tmp</workingDir>
          <command></command>
          <args>${computer.jnlpmac} ${computer.name}</args>
          <ttyEnabled>false</ttyEnabled>
          <resourceRequestCpu></resourceRequestCpu>
          <resourceRequestMemory></resourceRequestMemory>
          <resourceLimitCpu></resourceLimitCpu>
          <resourceLimitMemory></resourceLimitMemory>
          <envVars/>
        </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
      </containers>
      <envVars/>
      <annotations/>
      <imagePullSecrets/>
      <nodeProperties/>
    </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>

시작된 후 OpenShift 동기화 플러그인 은 OpenShift Container Platform의 API 서버를 모니터링하여 ImageStreams,ImageStreamTags, ConfigMaps 에 대한 업데이트를 확인하고 Kubernetes 플러그인의 구성을 조정합니다.

특히 다음 규칙이 적용됩니다.

컨테이너 이미지를 Jenkins 에이전트로 사용하려면 이미지가 슬레이브 에이전트를 진입점으로 실행해야 합니다. 이 작업에 대한 자세한 내용은 공식 Jenkins 문서를 참조하십시오.

템플릿 은 모든 환경 변수(암호)를 사전 정의된 기본값으로 정의하는 매개변수 필드를 제공합니다. OpenShift Container Platform은 새로운 Jenkins 서비스 생성을 용이하게 해주는 템플릿을 제공합니다. Jenkins 템플릿은 초기 클러스터 설정 중에 클러스터 관리자가 기본 openshift 프로젝트에 등록되어 있어야 합니다. 필요한 경우 자세한 내용은 기본 이미지 스트림 및 템플릿 로드 를 참조하십시오.

배포 구성 및 서비스.

Jenkins를 사용하려면 템플릿을 인스턴스화 해야 합니다.

비슷한 목표를 달성하는 풀 샘플은 여기에서 확인할 수 있습니다.

kind: List
apiVersion: v1
items:
- kind: ImageStream
  apiVersion: v1
  metadata:
    name: openshift-jee-sample
- kind: BuildConfig
  apiVersion: v1
  metadata:
    name: openshift-jee-sample-docker
  spec:
    strategy:
      type: Docker
    source:
      type: Docker
      dockerfile: |-
        FROM openshift/wildfly-101-centos7:latest
        COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
        CMD $STI_SCRIPTS_PATH/run
      binary:
        asFile: ROOT.war
    output:
      to:
        kind: ImageStreamTag
        name: openshift-jee-sample:latest
- kind: BuildConfig
  apiVersion: v1
  metadata:
    name: openshift-jee-sample
  spec:
    strategy:
      type: JenkinsPipeline
      jenkinsPipelineStrategy:
        jenkinsfile: |-
          node("maven") {
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
    triggers:
    - type: ConfigChange

동적으로 생성된 Jenkins 에이전트 포드의 사양을 재정의할 수도 있습니다. 다음은 컨테이너 메모리를 재정의하고 환경 변수를 지정하는 위 예제를 수정하는 것입니다.

kind: BuildConfig
apiVersion: v1
metadata:
  name: openshift-jee-sample
spec:
  strategy:
    type: JenkinsPipeline
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        podTemplate(label: "mypod", 1
                    cloud: "openshift", 2
                    inheritFrom: "maven", 3
                    containers: [
            containerTemplate(name: "jnlp", 4
                              image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 5
                              resourceRequestMemory: "512Mi", 6
                              resourceLimitMemory: "512Mi", 7
                              envVars: [
              envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 8
            ])
          ]) {
          node("mypod") { 9
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
        }
  triggers:
  - type: ConfigChange

기본적으로 Pod는 빌드가 완료되면 삭제됩니다. 이 동작은 플러그인을 통해 또는 pipeline Jenkinsfile 내에서 수정할 수 있습니다. 자세한 내용은 에이전트 Pod 보존을 참조하십시오.

Kubernetes 플러그인 구성에 대한 자세한 내용은 Kubernetes 플러그인 설명서를 참조하십시오.

제공된 Jenkins Ephemeral 또는 Jenkins Persistent 템플릿에서 배포하는 경우 기본 메모리 제한은 512MiB입니다.

Jenkins 에서 사용하는 JVM 튜닝에 대한 배경 정보는 OpenShift Container Platform에서 OpenJDK 를 참조하십시오.

메모리 효율성을 위해 기본적으로 Jenkins 이미지는 2GiB의 메모리 제한이 있는 컨테이너에서 실행되는 경우 32비트 JVM을 동적으로 사용합니다. 이 동작은 OPENSHIFT_JENKINS_JVM_ARCH 환경 변수로 재정의할 수 있습니다.

기본적으로 Jenkins JVM은 힙에 대해 컨테이너 메모리 제한의 50%를 사용합니다. 이 값은 CONTAINER_HEAP_PERCENT 환경 변수를 통해 수정할 수 있습니다. 상한값으로 제한하거나 완전히 재정의할 수도 있습니다. 자세한 내용은 환경 변수 를 참조하십시오.

파이프라인에서 로컬로 실행되는 쉘 스크립트 또는 oc 명령과 같이 Jenkins 컨테이너에서 실행되는 다른 모든 프로세스는 기본적으로 OOM 종료를 생성하지 않고 나머지 256MiB 메모리를 사용할 수 없다는 점을 고려하십시오. 따라서 가능한 경우 파이프라인은 에이전트 컨테이너에서 외부 명령을 실행하는 것이 좋습니다.

Jenkins 쿠버네티스 플러그인에 의해 생성된 에이전트 컨테이너에서 메모리 요청 및 제한 값을 지정하는 것이 좋습니다. admin은 Jenkins 구성을 통해 에이전트별 이미지에 기본값을 설정할 수 있습니다. 메모리 요청 및 제한은 위에 설명된 대로 컨테이너별로 덮어쓸 수도 있습니다.

Jenkins Ephemeral 또는 Jenkins Persistent 템플릿을 인스턴스화할 때 MEMORY_LIMIT paramenter를 재정의하여 Jenkins에서 사용할 수 있는 메모리 양을 늘릴 수 있습니다.

OpenShift Container Platform 클라이언트 플러그인은 OpenShift Container Platform과의 다양한 상호 작용을 위해 읽기 쉽고 간결하고 포괄적이며 유창한 Jenkins Pipeline 구문을 제공하는 것을 목표로 합니다. 플러그인은 스크립트를 실행하는 노드에서 사용할 수 있어야 하는 oc 바이너리를 활용합니다.

이 플러그인은 완전히 지원되며 Jenkins 이미지에 포함되어 있습니다. 다음을 제공합니다.

자세한 내용은 OpenShift Pipeline Builds 튜토리얼 과 플러그인의 README 를 참조하십시오.

OpenShift Container Platform Pipeline 플러그인은 OpenShift Container Platform 클라이언트 플러그인보다 적은 기능을 제공하는 Jenkins와 OpenShift Container Platform 간의 이전 통합입니다. 더 이상 사용되지 않지만 OpenShift Container Platform 버전에서 v3.11까지 계속 작동합니다. Jenkins 파이프라인에서 직접 oc 바이너리를 사용하거나 OpenShift Container Platform 클라이언트 플러그인 을 사용합니다.

자세한 내용은 플러그인의 README 를 참조하십시오.

Jenkins와 OpenShift Container Platform 간의 통합을 위한 OpenShift Container Platform Pipeline 빌드 전략을 지원하기 위해 OpenShift Sync Plug-in 은 OpenShift Container Platform의 API 서버를 모니터링하여 Pipeline 전략을 사용하는 BuildConfig 및 빌드 업데이트를 모니터링하고 Jenkins Pipeline 프로젝트를 생성합니다( BuildConfig 가 생성되면) 결과 프로젝트에서 작업을 시작합니다( 빌드 가 시작될 때).

Jenkins 쿠버네티스 플러그인 구성에서 설명한 대로 이 플러그인은 OpenShift Container Platform에 정의된 ImageStream,ImageStreamTag 또는 ConfigMap 오브젝트를 기반으로 Kubernetes 플러그인에 대한 PodTemplate 구성을 생성할 수 있습니다.

이 플러그인은 이제 credentials .sync.jenkins.openshift.io의 레이블 키로 Secret 오브젝트를 사용할 수 있으며 Jenkins 인증 정보 내에 기본 글로벌 도메인에 배치된 Jenkins 인증 정보를 구성합니다. 인증 정보 ID는 Secret 이 정의된 네임스페이스, 하이픈(-), 그 뒤에 Secret 의 이름으로 구성됩니다.

PodTemplate s 의 ConfigMap 처리와 유사하게 OpenShift Container Platform에 정의된 Secret 오브젝트는 마스터 구성으로 간주됩니다. OpenShift Container Platform에서 오브젝트에 대한 후속 업데이트는 Jenkins 자격 증명에 적용됩니다(중간에서 수행한 인증 정보에 대한 변경 사항 적용).

credential.sync.jenkins.openshift.io 속성, 해당 속성을 true 이외의 값으로 설정하거나 OpenShift Container Platform에서 시크릿 을 삭제하면 Jenkins에서 관련 인증 정보가 삭제됩니다.

시크릿 유형은 다음과 같이 jenkins 자격 증명 유형에 매핑됩니다.

Kubernetes 플러그인은 클러스터에서 Jenkins 에이전트를 포드로 실행하는 데 사용됩니다. Kubernetes 플러그인의 자동 구성은 Jenkins Kubernetes 플러그인 사용에서 설명합니다.

각 Jenkins 에이전트 컨테이너는 다음 환경 변수를 사용하여 구성할 수 있습니다.

JVM은 모든 Jenkins 에이전트에서 Jenkins JNLP 에이전트를 호스팅하고 Java 애플리케이션(예: javac, Maven 또는 Gradle)을 실행하는 데 사용됩니다. Jenkins 에이전트에서 사용하는 JVM 튜닝 에 대한 배경 정보는 OpenShift Container Platform에서 OpenJDK 를 참조하십시오.

메모리 효율성을 위해 기본적으로 Jenkins 이미지는 2GiB의 메모리 제한이 있는 컨테이너에서 실행되는 경우 32비트 JVM을 동적으로 사용합니다. 이 동작은 OPENSHIFT_JENKINS_JVM_ARCH 환경 변수로 재정의할 수 있습니다. JVM 선택은 기본적으로 Jenkins JNLP 에이전트와 에이전트 컨테이너 내의 다른 모든 Java 프로세스에 적용됩니다.

기본적으로 Jenkins JNLP 에이전트 JVM은 힙에 대해 컨테이너 메모리 제한의 50%를 사용합니다. 이 값은 CONTAINER_HEAP_PERCENT 환경 변수를 통해 수정할 수 있습니다. 상한값으로 제한하거나 완전히 재정의할 수도 있습니다. 자세한 내용은 환경 변수 를 참조하십시오.

기본적으로 Jenkins 에이전트 컨테이너에서 실행되는 기타 모든 프로세스(예: 파이프라인에서 실행되는 쉘 스크립트 또는 oc 명령은 OOM 종료를 프록시하지 않고 남은 50%의 메모리 제한을 초과할 수 없음을 고려할 수 있습니다.

기본적으로 Jenkins 에이전트 컨테이너에서 실행되는 각 JVM 프로세스는 힙에 대해 컨테이너 메모리 제한의 최대 25%를 사용합니다. 많은 빌드 워크로드에 대해 이 값을 조정해야 할 수도 있습니다. 자세한 내용은 OpenShift Container Platform에서 OpenJDK 를 참조하십시오.

Jenkins 에이전트 컨테이너의 메모리 요청 및 제한에 대한 정보는 Jenkins 문서 를 참조하십시오.