15.3. Lifecycle Agent를 사용하여 단일 노드 OpenShift 클러스터에 대한 이미지 기반 업그레이드 수행


Lifecycle Agent를 사용하여 단일 노드 OpenShift 클러스터의 수동 이미지 기반 업그레이드를 수행할 수 있습니다.

클러스터에 Lifecycle Agent를 배포하면 ImageBasedUpgrade CR이 자동으로 생성됩니다. 이 CR을 업데이트하여 시드 이미지의 이미지 리포지터리를 지정하고 다른 단계를 진행합니다.

15.3.1. Lifecycle Agent를 사용하여 이미지 기반 업그레이드의 Prep 단계로 이동

클러스터에 Lifecycle Agent를 배포하면 ImageBasedUpgrade CR(사용자 정의 리소스)이 자동으로 생성됩니다.

업그레이드 중에 필요한 모든 리소스를 생성한 후 Prep 단계로 이동할 수 있습니다. 자세한 내용은 "라이프사이클 에이전트를 사용한 이미지 기반 업그레이드에 대한 ConfigMap 오브젝트 생성" 섹션을 참조하십시오.

사전 요구 사항

  • 클러스터를 백업하고 복원하는 리소스를 생성했습니다.

프로세스

  1. ImageBasedUpgrade CR이 패치되었는지 확인합니다.

    apiVersion: lca.openshift.io/v1
    kind: ImageBasedUpgrade
    metadata:
      name: upgrade
    spec:
      stage: Idle
      seedImageRef:
        version: 4.15.2 1
        image: <seed_container_image> 2
        pullSecretRef: <seed_pull_secret> 3
      autoRollbackOnFailure: {}
    #    initMonitorTimeoutSeconds: 1800 4
      extraManifests: 5
      - name: example-extra-manifests-cm
        namespace: openshift-lifecycle-agent
      - name: example-catalogsources-cm
        namespace: openshift-lifecycle-agent
      oadpContent: 6
      - name: oadp-cm-example
        namespace: openshift-adp
    1
    대상 플랫폼 버전. 값은 시드 이미지 버전과 일치해야 합니다.
    2
    대상 클러스터에서 시드 이미지를 가져올 수 있는 리포지토리입니다.
    3
    이미지가 프라이빗 레지스트리에 있는 경우 컨테이너 이미지를 가져오는 인증 정보가 있는 보안에 대한 참조입니다.
    4
    선택 사항: 첫 번째 재부팅 후 업그레이드가 완료되지 않으면 롤백할 시간(초)입니다. 정의되지 않거나 0 으로 설정하면 1800 초(30분)의 기본값이 사용됩니다.
    5
    선택 사항: 업그레이드 후 유지할 사용자 정의 카탈로그 소스와 시드 이미지에 포함되지 않은 대상 클러스터에 적용할 추가 매니페스트가 포함된 ConfigMap 리소스 목록입니다.
    6
    OADP BackupRestore CR이 포함된 ConfigMap 리소스 목록입니다.
  2. Prep 단계를 시작하려면 다음 명령을 실행하여 ImageBasedUpgrade CR의 stage 필드 값을 Prep 로 변경합니다.

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agent

    OADP 리소스 및 추가 매니페스트에 ConfigMap 오브젝트를 제공하는 경우 Lifecycle Agent는 Prep 단계에서 지정된 ConfigMap 오브젝트를 검증합니다. 다음 문제가 발생할 수 있습니다.

    • Lifecycle Agent가 추가Manifests 매개변수와 관련된 문제를 감지하면 유효성 검사 경고 또는 오류입니다.
    • 라이프사이클 에이전트가 oadpContent 매개변수와 관련된 문제를 감지하면 유효성 검사 오류가 발생합니다.

    검증 경고는 업그레이드 단계를 차단하지 않지만 업그레이드를 진행하는 것이 안전한지 결정해야 합니다. 이러한 경고(예: 누락된 CRD, 네임스페이스 또는 예행 실행 실패)는 경고에 대한 세부 정보를 사용하여 ImageBasedUpgrade CR의 Prep stage 및 annotation 필드에 대한 status.conditions 를 업데이트합니다.

    검증 경고 예

    # ...
    metadata:
    annotations:
      extra-manifest.lca.openshift.io/validation-warning: '...'
    # ...

    그러나 MachineConfig 또는 Operator 매니페스트를 추가 매니페스트에 추가하는 것과 같은 검증 오류로 인해 Prep 단계가 실패하고 Upgrade 단계를 차단합니다.

    검증을 통과하면 클러스터에서 새 ostree stateroot를 생성합니다. 여기에는 시드 이미지를 가져오고 압축 해제하고 호스트 수준 명령을 실행하는 작업이 포함됩니다. 마지막으로 대상 클러스터에서 필요한 모든 이미지가 미리 캐시됩니다.

검증

  • 다음 명령을 실행하여 ImageBasedUpgrade CR의 상태를 확인합니다.

    $ oc get ibu -o yaml

    출력 예

      conditions:
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: In progress
        observedGeneration: 13
        reason: InProgress
        status: "False"
        type: Idle
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Prep completed
        observedGeneration: 13
        reason: Completed
        status: "False"
        type: PrepInProgress
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Prep stage completed successfully
        observedGeneration: 13
        reason: Completed
        status: "True"
        type: PrepCompleted
      observedGeneration: 13
      validNextStages:
      - Idle
      - Upgrade

15.3.2. Lifecycle Agent를 사용하여 이미지 기반 업그레이드의 업그레이드 단계로 이동

시드 이미지를 생성하고 Prep 단계를 완료한 후 대상 클러스터를 업그레이드할 수 있습니다. 업그레이드 프로세스 중에 OADP Operator는 OADP CR(사용자 정의 리소스)에 지정된 아티팩트 백업을 생성한 다음 Lifecycle Agent가 클러스터를 업그레이드합니다.

업그레이드가 실패하거나 중지되면 자동 롤백이 시작됩니다. 업그레이드 후 문제가 있는 경우 수동 롤백을 시작할 수 있습니다. 수동 롤백에 대한 자세한 내용은 "라이프사이클 에이전트를 사용한 이미지 기반 업그레이드의 롤백 단계"를 참조하십시오.

사전 요구 사항

  • Prep 단계를 완료했습니다.

프로세스

  1. 업그레이드 단계로 이동하려면 다음 명령을 실행하여 ImageBased Upgrade CR에서 stage 필드의 값을 Upgrade로 변경합니다.

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Upgrade"}}' --type=merge
  2. 다음 명령을 실행하여 ImageBasedUpgrade CR의 상태를 확인합니다.

    $ oc get ibu -o yaml

    출력 예

    status:
      conditions:
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: In progress
        observedGeneration: 5
        reason: InProgress
        status: "False"
        type: Idle
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Prep completed
        observedGeneration: 5
        reason: Completed
        status: "False"
        type: PrepInProgress
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Prep completed successfully
        observedGeneration: 5
        reason: Completed
        status: "True"
        type: PrepCompleted
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: |-
          Waiting for system to stabilize: one or more health checks failed
            - one or more ClusterOperators not yet ready: authentication
            - one or more MachineConfigPools not yet ready: master
            - one or more ClusterServiceVersions not yet ready: sriov-fec.v2.8.0
        observedGeneration: 1
        reason: InProgress
        status: "True"
        type: UpgradeInProgress
      observedGeneration: 1
      rollbackAvailabilityExpiration: "2024-05-19T14:01:52Z"
      validNextStages:
      - Rollback

    OADP Operator는 OADP BackupRestore CR에 지정된 데이터 백업을 생성하고 대상 클러스터가 재부팅됩니다.

  3. 다음 명령을 실행하여 CR의 상태를 모니터링합니다.

    $ oc get ibu -o yaml
  4. 업그레이드에 만족하는 경우 다음 명령을 실행하여 ImageBasedUpgrade CR의 stage 필드 값을 Idle 에 패치하여 변경 사항을 완료합니다.

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge
    중요

    업그레이드 후 Idle 단계로 이동한 후에는 변경 사항을 롤백할 수 없습니다.

    Lifecycle Agent는 업그레이드 프로세스 중에 생성된 모든 리소스를 삭제합니다.

  5. 업그레이드 후 OADP Operator 및 해당 구성 파일을 제거할 수 있습니다. 자세한 내용은 "클러스터에서 Operator 삭제"를 참조하십시오.

검증

  1. 다음 명령을 실행하여 ImageBasedUpgrade CR의 상태를 확인합니다.

    $ oc get ibu -o yaml

    출력 예

    status:
      conditions:
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: In progress
        observedGeneration: 5
        reason: InProgress
        status: "False"
        type: Idle
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Prep completed
        observedGeneration: 5
        reason: Completed
        status: "False"
        type: PrepInProgress
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Prep completed successfully
        observedGeneration: 5
        reason: Completed
        status: "True"
        type: PrepCompleted
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Upgrade completed
        observedGeneration: 1
        reason: Completed
        status: "False"
        type: UpgradeInProgress
      - lastTransitionTime: "2024-01-01T09:00:00Z"
        message: Upgrade completed
        observedGeneration: 1
        reason: Completed
        status: "True"
        type: UpgradeCompleted
      observedGeneration: 1
      rollbackAvailabilityExpiration: "2024-01-01T09:00:00Z"
      validNextStages:
      - Idle
      - Rollback

  2. 다음 명령을 실행하여 클러스터 복원 상태를 확인합니다.

    $ oc get restores -n openshift-adp -o custom-columns=NAME:.metadata.name,Status:.status.phase,Reason:.status.failureReason

    출력 예

    NAME             Status      Reason
    acm-klusterlet   Completed   <none> 1
    apache-app       Completed   <none>
    localvolume      Completed   <none>

    1
    acm-klusterlet 은 RHACM 환경에만 적용됩니다.

15.3.3. Lifecycle Agent를 사용하여 이미지 기반 업그레이드의 롤백 단계로 이동

재부팅 후 initMonitorTimeoutSeconds 필드에 지정된 시간 내에 업그레이드가 완료되지 않으면 자동 롤백이 시작됩니다.

ImageBasedUpgrade CR의 예

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle
  seedImageRef:
    version: 4.15.2
    image: <seed_container_image>
  autoRollbackOnFailure: {}
#    initMonitorTimeoutSeconds: 1800 1
# ...

1
선택 사항: 업그레이드가 첫 번째 재부팅 후 해당 기간 내에 완료되지 않으면 롤백할 시간(초)입니다. 정의되지 않거나 0 으로 설정하면 1800 초(30분)의 기본값이 사용됩니다.

업그레이드 후 해결할 수 없는 문제가 발생하면 변경 사항을 수동으로 롤백할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 원래 stateroot의 컨트롤 플레인 인증서가 유효한지 확인했습니다. 인증서가 만료된 경우 "종료된 컨트롤 플레인 인증서에서 복구"를 참조하십시오.

프로세스

  1. 롤백 단계로 이동하려면 다음 명령을 실행하여 stage 필드의 값을 ImageBasedUpgrade CR의 롤백 에 패치합니다.

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Rollback"}}' --type=merge

    Lifecycle Agent는 이전에 설치한 OpenShift Container Platform 버전으로 클러스터를 재부팅하고 애플리케이션을 복원합니다.

  2. 변경 사항에 만족하는 경우 다음 명령을 실행하여 ImageBasedUpgrade CR의 stage 필드 값을 Idle 에 패치하여 롤백을 완료합니다.

    $ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Idle"}}' --type=merge -n openshift-lifecycle-agent
    주의

    롤백 후 Idle 단계로 이동하는 경우 Lifecycle Agent는 업그레이드 실패 문제를 해결하는 데 사용할 수 있는 리소스를 정리합니다.

15.3.4. Lifecycle Agent를 사용하여 이미지 기반 업그레이드 문제 해결

문제의 영향을 받는 관리 클러스터에서 문제 해결 단계를 수행합니다.

중요

ImageBasedGroupUpgrade CR을 사용하여 클러스터를 업그레이드하는 경우 관리 클러스터에서 문제 해결 또는 복구 단계를 수행한 후 lcm.openshift.io/ibgu-<stage>-completed 또는 'lcm.openshift.io/ibgu-<stage >가 올바르게 업데이트되었는지 확인합니다. 이렇게 하면 TALM에서 클러스터의 이미지 기반 업그레이드를 계속 관리합니다.

15.3.4.1. 로그 수집

oc adm must-gather CLI를 사용하여 디버깅 및 문제 해결을 위한 정보를 수집할 수 있습니다.

프로세스

  • 다음 명령을 실행하여 Operator에 대한 데이터를 수집합니다.

    $  oc adm must-gather \
      --dest-dir=must-gather/tmp \
      --image=$(oc -n openshift-lifecycle-agent get deployment.apps/lifecycle-agent-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name == "manager")].image}') \
      --image=quay.io/konveyor/oadp-must-gather:latest \// 1
      --image=quay.io/openshift/origin-must-gather:latest 2
    1
    선택 사항: OADP Operator에서 자세한 정보를 수집해야 하는 경우 이 옵션을 추가합니다.
    2
    선택 사항: SR-IOV Operator에서 자세한 정보를 수집해야 하는 경우 이 옵션을 추가합니다.

15.3.4.2. AbortFailed 또는 CryostatFailed 오류

문제

종료 단계 중 또는 사전 단계에서 프로세스를 중지하면 Lifecycle Agent에서 다음 리소스를 정리합니다.

  • 더 이상 필요하지 않은 Stateroot
  • 리소스 사전 처리
  • OADP CR
  • ImageBasedUpgrade CR

라이프 사이클 에이전트가 위의 단계를 수행하지 못하면 AbortFailed 또는 CryostatFailed 상태로 전환됩니다. 조건 메시지와 log는 실패한 단계를 표시합니다.

오류 메시지의 예

message: failed to delete all the backup CRs. Perform cleanup manually then add 'lca.openshift.io/manual-cleanup-done' annotation to ibu CR to transition back to Idle
      observedGeneration: 5
      reason: AbortFailed
      status: "False"
      type: Idle

해결
  1. 로그를 검사하여 실패가 발생한 이유를 확인합니다.
  2. Lifecycle Agent에서 정리를 다시 시도하도록 요청하려면 lca.openshift.io/manual-cleanup-done 주석을 ImageBasedUpgrade CR에 추가합니다.

    이 주석을 관찰한 후 Lifecycle Agent에서 정리를 다시 시도한 후 성공한 경우 ImageBasedUpgrade 단계가 Idle 으로 전환됩니다.

    정리가 다시 실패하면 리소스를 수동으로 정리할 수 있습니다.

15.3.4.2.1. 수동으로 stateroot 정리
문제
Prep 단계에서 중지하면 Lifecycle Agent가 새 stateroot를 정리합니다. 업그레이드 또는 롤백을 성공적으로 완료한 후 Lifecycle Agent가 이전 stateroot를 정리합니다. 이 단계가 실패하면 로그를 검사하여 실패한 이유를 확인하는 것이 좋습니다.
해결
  1. 다음 명령을 실행하여 stateroot에 기존 배포가 있는지 확인합니다.

    $ ostree admin status
  2. 해당하는 경우 다음 명령을 실행하여 기존 배포를 정리합니다.

    $ ostree admin undeploy <index_of_deployment>
  3. stateroot의 모든 배포를 정리한 후 다음 명령을 실행하여 stateroot 디렉터리를 지웁니다.

    주의

    booted 배포가 이 stateroot에 없는지 확인합니다.

    $ stateroot="<stateroot_to_delete>"
    $ unshare -m /bin/sh -c "mount -o remount,rw /sysroot && rm -rf /sysroot/ostree/deploy/${stateroot}"
15.3.4.2.2. 수동으로 OADP 리소스 정리
문제
Lifecycle Agent와 S3 백엔드 간의 연결 문제로 인해 OADP 리소스의 자동 정리가 실패할 수 있습니다. 연결을 복원하고 lca.openshift.io/manual-cleanup-done 주석을 추가하면 Lifecycle Agent에서 백업 리소스를 성공적으로 정리할 수 있습니다.
해결
  1. 다음 명령을 실행하여 백엔드 연결을 확인합니다.

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    출력 예

    NAME                          PHASE       LAST VALIDATED   AGE   DEFAULT
    dataprotectionapplication-1   Available   33s              8d    true

  2. 모든 백업 리소스를 제거한 다음 lca.openshift.io/manual-cleanup-done 주석을 ImageBasedUpgrade CR에 추가합니다.

15.3.4.3. LVM 스토리지 볼륨 콘텐츠가 복원되지 않음

LVM 스토리지를 사용하여 동적 영구 볼륨 스토리지를 제공하는 경우 LVM 스토리지에서 영구 볼륨 콘텐츠가 잘못 구성된 경우 복원되지 않을 수 있습니다.

15.3.4.3.1. Backup CR에서 누락된 LVM 스토리지 관련 필드
문제

Backup CR은 영구 볼륨을 복원하는 데 필요한 누락된 필드일 수 있습니다. 다음을 실행하여 애플리케이션 Pod의 이벤트를 확인하여 이 문제가 있는지 확인할 수 있습니다.

$ oc describe pod <your_app_name>

Backup CR에서 누락된 LVM 스토리지 관련 필드를 표시하는 출력 예

Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  58s (x2 over 66s)  default-scheduler  0/1 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling..
  Normal   Scheduled         56s                default-scheduler  Successfully assigned default/db-1234 to sno1.example.lab
  Warning  FailedMount       24s (x7 over 55s)  kubelet            MountVolume.SetUp failed for volume "pvc-1234" : rpc error: code = Unknown desc = VolumeID is not found

해결

application Backup CR에 logicalvolumes.topolvm.io 를 포함해야 합니다. 이 리소스가 없으면 애플리케이션에서 영구 볼륨 클레임 및 영구 볼륨 매니페스트를 올바르게 복원하지만 피벗 후 이 영구 볼륨과 연결된 논리 볼륨이 올바르게 복원되지 않습니다.

Backup CR의 예

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: small-app
  namespace: openshift-adp
spec:
  includedNamespaces:
  - test
  includedNamespaceScopedResources:
  - secrets
  - persistentvolumeclaims
  - deployments
  - statefulsets
  includedClusterScopedResources: 1
  - persistentVolumes
  - volumesnapshotcontents
  - logicalvolumes.topolvm.io

1
애플리케이션의 영구 볼륨을 복원하려면 다음과 같이 이 섹션을 구성해야 합니다.
15.3.4.3.2. CR 복원에서 누락된 LVM 스토리지 관련 필드
문제

애플리케이션에 필요한 리소스가 복원되지만 업그레이드 후에는 영구 볼륨 콘텐츠가 보존되지 않습니다.

  1. 피벗 전에 다음 명령을 실행하여 애플리케이션의 영구 볼륨을 나열합니다.

    $ oc get pv,pvc,logicalvolumes.topolvm.io -A

    피벗 전 출력 예

    NAME                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
    persistentvolume/pvc-1234   1Gi        RWO            Retain           Bound    default/pvc-db   lvms-vg1                4h45m
    
    NAMESPACE   NAME                           STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    default     persistentvolumeclaim/pvc-db   Bound    pvc-1234   1Gi        RWO            lvms-vg1       4h45m
    
    NAMESPACE   NAME                                AGE
                logicalvolume.topolvm.io/pvc-1234   4h45m

  2. 피벗 후 다음 명령을 실행하여 애플리케이션의 영구 볼륨을 나열합니다.

    $ oc get pv,pvc,logicalvolumes.topolvm.io -A

    피벗 후 출력 예

    NAME                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
    persistentvolume/pvc-1234   1Gi        RWO            Delete           Bound    default/pvc-db   lvms-vg1                19s
    
    NAMESPACE   NAME                           STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    default     persistentvolumeclaim/pvc-db   Bound    pvc-1234   1Gi        RWO            lvms-vg1       19s
    
    NAMESPACE   NAME                                AGE
                logicalvolume.topolvm.io/pvc-1234   18s

해결

이 문제의 원인은 logicalvolume 상태가 Restore CR에 유지되지 않기 때문입니다. 이 상태는 Velero가 피벗 후 보존해야 하는 볼륨을 참조하는 데 필요하기 때문에 중요합니다. 애플리케이션 Restore CR에 다음 필드를 포함해야 합니다.

Restore CR의 예

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: sample-vote-app
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "3"
spec:
  backupName:
    sample-vote-app
  restorePVs: true 1
  restoreStatus: 2
    includedResources:
      - logicalvolumes

1
애플리케이션의 영구 볼륨을 유지하려면 restorePVtrue 로 설정해야 합니다.
2
애플리케이션의 영구 볼륨을 유지하려면 표시된 대로 이 섹션을 구성해야 합니다.

15.3.4.4. 실패한 Backup 및 Restore CR 디버깅

문제
아티팩트의 백업 또는 복원에 실패했습니다.
해결

BackupRestore CR을 디버그하고 Velero CLI 툴을 사용하여 로그를 검색할 수 있습니다. Velero CLI 툴은 OpenShift CLI 툴보다 자세한 정보를 제공합니다.

  1. 다음 명령을 실행하여 오류가 포함된 Backup CR을 설명합니다.

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe backup -n openshift-adp backup-acm-klusterlet --details
  2. 다음 명령을 실행하여 오류가 포함된 Restore CR을 설명합니다.

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero describe restore -n openshift-adp restore-acm-klusterlet --details
  3. 다음 명령을 실행하여 백업된 리소스를 로컬 디렉터리에 다운로드합니다.

    $ oc exec -n openshift-adp velero-7c87d58c7b-sw6fc -c velero -- ./velero backup download -n openshift-adp backup-acm-klusterlet -o ~/backup-acm-klusterlet.tar.gz
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.