[Jenkins] AWS EC2에 컨테이너 배포하기

Jenkins에서 빌드한 컨테이너 이미지를 EC2에 배포하는 작업을 진행해보겠습니다.
사전에 컨테이너 빌드 작업 완료 후 AWS ECR(Elastic Container Registry)에 업로드하는 작업을 생성해둔 상태입니다.

 

 


플러그인 설치

우선 Jenkins에서 빌드한 컨테이너 이미지를 EC2에 배포하기 위해서는 SSH 접속을 통한 접근이 필요한데요.
Jenkins에서 EC2에 SSH 접속을 하기 위해서는 플러그인을 설치해야됩니다.


설치해야되는 플러그인은 SSH Agent Plugin 입니다.

 

 


SSH Key 발급 및 적용

SSH 접속은 Key를 통해 접속하므로 Key 발급 및 적용 작업을 진행합니다.

 

SSH Key 발급

ssh-keygen 명령어를 통해 개인키(id_rsa)와 공개키(id_rsa.pub)를 발급합니다.

 

EC2 공개키(id_rsa.pub) 적용

발급한 키 중 공개키(id_rsa.pub)를 배포하고자 하는 EC2에 적용합니다.
적용하고자 하는 접속 계정의 ~/.ssh/authorized_keys 파일에 공개키를 복사합니다.

### ssh-copy-id 명령어로 복사
ssh-copy-id {HOSTNAME}@{IP}
EX) ssh-copy-id ec2-user@10.1.1,1

### cat 명령어로 복사
cat .ssh/id_rsa.pub >> .ssh/authorized_keys

### vi로 파일 내용 추가
vi .ssh/authorized_keys
key 값 복사

 

EC2 서버로 직접 접속하여 공개키(id_rsa.pub)가 정상적으로 적용되었는지 확인합니다.

cat .ssh/authorized_keys
ssh-rsa ##############################################################################
######################################################################################
################################### root@ip-10-1-1-205.ap-northeast-2.compute.internal

 

 


Jenkins 개인키(id_rsa) 적용

SSH Agent를 통해 EC2를 접속하기 위해 사전에 발급한 SSH Key 중 개인키(id_rsa)를 Credentials로 등록합니다.


개인키(id_rsa)는 Dashboard -> Jenkins 관리 -> Credentials 메뉴에서 등록합니다.

 

 

Credentials 발급 시 Kind는 SSH Username with private key를 선택합니다.
사용하고자 하는 ID와 Username을 지정합니다.

 

 

Private Key 값은 Enter directly 버튼을 클릭하여 직접 개인키(id_rsa)를 입력할 수 있도록 합니다.
개인키(id_rsa)를 Key에 입력 후 Create 버튼을 클릭하여 Credentials 등록을 완료합니다.

 

 


Jenkins Pipeline 설정

SSH Agent 플러그인을 사용하여 사전에 등록한 Credentials을 통해 EC2 접속 및 배포 작업을 진행해보도록 하겠습니다.

stage('deploy-EC2') {
  steps {
    //SSH Agent 플러그인을 사용하여 사전에 등록한 Credentials 지정
    sshagent (credentials: ['EC2_ACCESS_KEY_ID']) {
      sh """
        ### ssh 명령어로 EC2 서버 지정
        ssh -o StrictHostKeyChecking=no ${EC2_USER}@${EC2_IP} '
          ### 실행할 명령어 입력        
          cd ${WORK_DIR}
          docker compose down
          docker pull ${AWS_ECR}/${IMAGE_NAME}:${IMAGE_TAG}
          docker compose up -d
          exit
        '
      """
    }
  }
}

 

  1. sshagent() 구분을 통해 SSH Agent 플러그인을 사용할 수 있도록 지정합니다.
  2. credentials:[] 값에는 사전에 등록한 Credentials을 지정합니다.
  3. ssh 명령어로 접속 및 배포하고자 하는 EC2 서버를 지정합니다.
  4. 실행할 명령어를 입력합니다.
    • 작업 디렉토리 이동
    • 도커 컨테이너 종료
    • 도커 컨테이너 이미지 다운로드
    • 도커 컨테이너 시작

 

위 작업을 통해 Jenkins에서 EC2 접속 및 배포 작업을 진행할 수 있습니다.

실행할 명령어에 따라 배포 작업을 진행하거나, 테스트, 모니터링 등 다양한 작업을 할 수도 있습니다.

 

 

지금까지 Jenkins에서 빌드한 컨테이너 이미지를 EC2에 배포하는 작업을 알아보는 시간이었습니다....! 끝...!

 

 

 

[Reference]

 

 

[Docker] error: could not create a builder instance with TLS data loaded from environment 에러 해결 방법

 

아래 docker buildx 명령어 사용 시 에러가 발생하였는데요.

$ docker buildx create --name multiple-arch-builder --use
error: could not create a builder instance with TLS data loaded from environment. Please use `docker context create <context-name>` to create a context for current environment and then create a builder instance with `docker buildx create <context-name>`

 

해당 에러는 docker Buildx 명령어를 사용하여 도커 이미지를 빌드하려고 할 때 발생할 수 있는 문제이며,
TLS 데이터를 환경에서 로드하는 동안 빌더 인스턴스를 생성할 수 없다는 것을 나타냅니다.

 

 

해당 에러를 해결하기 위해서는 docker context create <context-name> 명령을 사용하여 도커 컨텍스트를 생성하고, docker buildx create <context-name> 명령어을 사용하여 도커 컨텍스트를 지정한 후 빌더 인스턴스를 생성해야 TLS 설정과 같은 인증 정보를 제공하면서 에러가 발생하지 않습니다.

 

 

아래와 같이 로직을 수정하면서 해당 에러를 해결하였습니다.

# 도커 컨텍스트 생성
$ docker context create multiple-arch-context
Successfully created context "multiple-arch-context"
multiple-arch-context

# 빌더 인스턴스를 생성 시 도커 컨텍스트 지정
$ docker buildx create multiple-arch-context --name multiple-arch-builder --use
multiple-arch-builder

 

 

지금까지 docker buildx 명령어 사용 시 에러 확인 및 해결 방법에 대해 알아보는 시간이었습니다....! 끝...!

'Docker' 카테고리의 다른 글

[Docker] Network 설정  (0) 2022.12.01
[Docker] Logging 설정  (0) 2022.11.07
[Docker] Syslog 서버 구축  (0) 2022.11.01
[Docker] Healthcheck 설정을 통한 컨테이너 상태 점검  (0) 2022.10.19
[Docker] Volumes 설정  (0) 2022.10.11

[AWS] Amazon Elastic Container Registry 알아보기

요즘 IT 업계에서는 테스트 환경, 개발 환경, 서비스 환경 등을 도커 컨테이너를 통해 많이 구현하고 사용하고 있습니다.
이런 도커 컨테이너의 이미지를 관리하기 위해서는 컨테이너 레지스트리를 통해 업로드 및 다운로드하여 사용하고 있는데요. 그 중 가장 많이 사용하고 대표적인 Docker Hub가 있지만 오늘은 Amazon에서 제공하는 Elastic Container Registry(ECR) 서비스에 대해 알아보고자 합니다.

 

 


개요

Amazon Elastic Container Registry (ECR)은 AWS에서 제공하는 관리형 도커 컨테이너 이미지 저장소입니다.


사용자(개발자)들은 ECR을 사용하여 컨테이너 이미지를 안전하게 저장하고 관리할 수 있는데요. ECR은 AWS에서 제공하는 EC2 인스턴스, ECS 클러스터, EKS 클러스터, AWS Fargate 등과 함께 사용할 수 있으며, 이를 통해 개발자들은 ECR에 저장된 컨테이너 이미지를 손쉽게 배포하고 실행할 수 있습니다.

 

 


기능

 

작동 방식

Amazon Elastic Container Registry (ECR)는 사용자가 도커 컨테이너 이미지를 안정적으로 관리하고 배포할 수 있도록 지원하고 있으며, AWS에서 제공하는 다양한 환경 및 On premises 에서 사용할 수 있습니다.

 

상세 기능

Amazon Elastic Container Registry (ECR)의 상세 기능을 정리해봤습니다.

 

  • 컨테이너 이미지 저장 및 관리
    • ECR은 도커 컨테이너 이미지를 중앙 집중화된 저장소에 안전하게 저장하고 관리합니다.
    • 이미지를 ECR에 업로드하여 버전 관리, 보안 및 접근 제어를 적용할 수 있습니다.
  • 보안 및 액세스 제어
    • ECR은 AWS Identity and Access Management (IAM)을 사용하여 액세스 제어를 구현합니다.
    • 사용자는 이미지에 대한 액세스 권한을 정교하게 구성하여 필요한 보안 수준을 유지할 수 있습니다.
  • 통합 및 배포
    • ECR은 다른 AWS에서 제공하는 다양한 서비스 및 환경과 통합되서 사용할 수 있습니다.
    • 예를 들어, EC2 인스턴스, ECS 클러스터, EKS 클러스터, AWS Fargate 등과 함께 사용하여 컨테이너 이미지를 배포하고 실행할 수 있습니다.
  • 이미지 레지스트리 및 태그 관리
    • ECR은 이미지 레지스트리를 제공하여 개발자가 이미지를 조직적으로 구성할 수 있도록 합니다.
    • 또한, 이미지에 태그를 할당하여 버전 관리를 용이하게 할 수 있습니다. 태그를 사용하여 특정 버전의 이미지를 식별하고 추적할 수 있습니다.
  • 이미지 스캔 및 취약점 관리
    • ECR은 컨테이너 이미지를 스캔하고 보안 취약점을 검출할 수 있습니다.
    • 이를 통해 개발자는 이미지의 보안 수준을 유지하고 취약점을 해결할 수 있습니다.
  • 확장성 및 신뢰성
    • ECR은 AWS의 글로벌 인프라스트럭처를 기반으로 하며, 안정적이고 확장 가능한 서비스입니다.
    • 개발자는 필요에 따라 컨테이너 이미지의 저장 용량을 증가시킬 수 있으며, 고가용성과 신뢰성을 보장합니다.

 

 

저는 여러 기능 중 이미지 스캔 및 취약점 관리 기능이 가장 좋다고 생각했는데요.
Private Docker Container Registry를 구축하거나 Docker Hub을 사용한다면 보안 취약점 부분은 쉽게 놓치고 갈 수 있기 때문에 꼭 필요한 기능이라고 생각됩니다.

 

 


요금

Amazon Elastic Container Registry (ECR)의 요금 정보를 정리해봤습니다.

 

 

기본적으로 요금은 데이터 저장 용량과 데이터 전송 용량에 따라 계산되는데요.
데이터 저장 용량은 월 기준 10GB 당 1 USD로 모든 리전에서 동일한 것으로 확인됩니다.

 

 

데이터 전송 용량은 도커 컨테이너 이미지를 업로드하는 경우에는 무료이며, 인터넷 환경이나 다른 리전에서 도커 컨테이너 이미지를 다운로드하는 경우에는 사용량에 따라 요금이 측정됩니다. 같은 리전은 무료이며 리전에 따라 요금은 조금 다른 것으로 확인되며 아래 사진을 통해 추가적인 정보를 확인해보시면 좋을 것 같습니다.

 

 


활용

Amazon Elastic Container Registry (ECR)를 활용하는 방법입니다.


우선 위에서 설명해드린 내용으로 단순하게 도커 컨테이너 이미지를 저장하여 관리할 뿐만 아니라 버전관리, 액세스 제어, 이미지 스캔 및 보안 취약점 점검, 확장 등 다양한 기능을 활용해보실 수 있습니다.

 

실제 도커 컨테이너 이미지를 관리해야 되는 상황이라면 어떤 컨테이너 레지스트리 서비스를 사용할지 고민이 되실 겁니다. 제 개인적인 의견으로는 AWS Cloud 환경에서 서비스를 배포하거나 개발 환경이 있다면 Amazon ECR을 활용하면 좋을 것 같고, 그렇지 않다면 그 외의 Container Registry 서비스를 찾아보시고 비교해보신 다음 사용하시는 것도 좋을 것 같습니다.

 


그 외의 Container Registry 서비스

Amazon Elastic Container Registry (ECR) 외의 다른 Container Registry 서비스를 단간히 알아보겠습니다.

 

 

가장 널리 알려진 오픈 소스 컨테이너 레지스트트리인 Docker Hub부터,
Google에서 제공하는 Google Container Registry,
Azure에서 제공하는 Azure Container Registry,
네이버에서 제공하는 Naver Cloud Container Registry 등이 있습니다.

 

각각의 Container Registry 서비스마다 기능, 특징, 요금이 다르므로
사용하고자하는 환경에 맞는 Container Registry를 선택 후 사용하시기 바랍니다.

 

 

 

지금까지 Amazon의 Elastic Container Registry를 알아보는 시간이었습니다....! 끝...!

 

 

 

[Reference]

 

 

'AWS' 카테고리의 다른 글

[AWS] AWS Direct Connect 알아보기  (0) 2023.07.12
[AWS] Amazon SNS 알아보기  (0) 2023.07.11
[AWS] Insufficient capacity error 에러  (0) 2023.05.23
[AWS] Service Quota 알아보기  (0) 2023.05.22
[AWS] AWS Summit Seoul 2023 2일차  (0) 2023.05.04

[Jenkins] AWS ECR에 컨테이너 이미지 업로드하기

Jenkins에서 빌드한 컨테이너 이미지를 AWS ECR(Elastic Container Registry)에 업로드하는 작업을 진행해보겠습니다.
사전에 AWS ECR(Elastic Container Registry)은 생성해둔 상태입니다.

 

 


간단히 ECR 알아보기


사전에 간단히 ECR이 무엇인지 알아보겠습니다.

 

AWS ECR (Amazon Elastic Container Registry)은 Amazon에서 제공하는 Docker 컨테이너 이미지를 저장하고 관리하기 위한 완전관리형 Docker 이미지 저장소입니다. ECR을 사용하면 보안 및 확장성이 뛰어난 프라이빗 이미지 저장소를 손쉽게 생성하고 Docker 컨테이너를 배포할 수 있으며, Amazon ECS (Elastic Container Service) 및 Amazon EKS (Elastic Kubernetes Service)와 통합되어 원활한 컨테이너 관리를 제공할 수 있습니다.

 

 

 


플러그인 설치

우선 Jenkins에서 AWS ECR에 컨테이너 이미지를 업로드하기 위해서는 플러그인을 설치해야됩니다.
설치해야되는 플러그인은 Amazon ECR plugin 입니다.

 

 


AWS Credentials 등록

AWS ECR(Elastic Container Registry)의 Private Repositories를 접근하기 위해서는 Access Key와 Secret Key를 통한 인증이 필요합니다.


플러그인 설치 완료 후 Jenkins 관리 탭을 확인하면 AWS 메뉴가 추가되어 있습니다.

 

 

AWS 메뉴를 통해 AWS Credentials을 등록합니다.

 

 

Kind는 AWS Credentials를 선택합니다.

 

 

이후 설정하고자 하는 Access Key와 Secret Key를 설정하고 저장합니다.

 

 

마지막으로 Region을 선택하고 저장하면 AWS Credentials 등록은 완료됩니다.

 

 


Pipeline 설정

Pipeline script에서 제공하는 docker.builddocker.withRegistry 기능을 통해 Jenkins에서 빌드한 컨테이너 이미지를 AWS ECR(Elastic Container Registry)에 업로드 할 수 있습니다.


사전에 Build 환경이 구성되어야 하며 Dockerfile이 작성되어 docker build 명령어로 바로 도커 컨테이너 빌드가 가능한 상태로 세팅되어야 합니다.

stage('build_and_upload_docker') {
  steps {
    script {
      // 도커 컨테이너 이미지 빌드
      build_data = docker.build("${ECR_ID}.dkr.ecr.ap-northeast-2.amazonaws.com/${IMAGE_NAME}:latest")

      // 도커 컨테이너 이미지 업로드
      // `AWS_CREDENTIALS_ID` 값은 사전에 등록한 AWS Credentials 정보
      docker.withRegistry("https://${ECR_ID}.dkr.ecr.ap-northeast-2.amazonaws.com", "ecr:ap-northeast-2:${AWS_CREDENTIALS_ID}") {
        build_data.push("${TAG_NAME}")
      }
    )
  }
}

위 작업의 내용은 아래와 같습니다.

  • docker.build를 통해 도커 컨테이너 이미지 빌드 작업을 진행합니다.
  • 빌드 작업을 완료하면 완료한 정보는 build_data에 저장합니다.
  • docker.withRegistry를 통해 AWS ECR에 접근합니다.
  • build_data의 push를 통해 저장하고자 하는 TAG 이름으로 AWS ECR에 빌드한 도커 컨테이너 이미지를 업로드 합니다.

${ECR_ID}, ${IMAGE_NAME}, ${AWS_CREDENTIALS_ID}, ${TAG_NAME} 값은 자신에 환경에 맞는 값을 설정하시면 됩니다.

 

 

성공적으로 Jenkins에서 빌드한 컨테이너 이미지를 AWS ECR(Elastic Container Registry)에 업로드 완료하면 아래와 같이 AWS ECR(Elastic Container Registry) 관리 페이지에서 업로드된 도커 컨테이너 이미지를 확인하실 수 있습니다.

 

 


활용

위에 작성한 Pipeline 설정 부분은 기본적인 방법으로 Jenkins에서 빌드한 컨테이너 이미지를 AWS ECR(Elastic Container Registry)에 업로드하는 작업입니다.


옵션 등을 사용하여 실제 업무에서 활용했던 부분을 간략히 추려보았습니다.

pipeline {
  agent any

  // 환경 변수 세팅
  environment {
    AWS_ECR = '123456789.dkr.ecr.ap-northeast-2.amazonaws.com'
    AWS_IMAGE_NAME= 'test'
    AWS_REGION = 'ap-northeast-2'
    AWS_CREDENTIALS_ID = 'AWS_CREDENTIALS_ID_VALUE'
  }

  stage('build_and_upload_docker') {
    steps {
      script {
        // 도커 컨테이너 이미지 빌드
        // -f 등 추가적인 옵션 추가
        build_data = docker.build(
          "${AWS_ECR}/${AWS_IMAGE_NAME}:latest",
          ". -f Dockerfile.patch +@ ETC OPTION"
        )

        // 도커 컨테이너 이미지 업로드
        // Branch 이름 및 기타 정보 등으로 TAG 생성
        docker.withRegistry("https://${AWS_ECR}", "ecr:${AWS_REGION}:${AWS_CREDENTIALS_ID}") {
          build_data.push("${env.gitlabBranch}")
          build_data.push("${env.gitlabBranch}-${env.BUILD_NUMBER}")
          build_data.push("${env.gitlabBranch}-${env.GIT_COMMIT}")
          build_data.push("${env.gitlabBranch}-latest")
        }
      )
    }
  }
}

 

 

 

지금까지 Jenkins에서 빌드한 컨테이너 이미지를 AWS ECR(Elastic Container Registry)에 업로드하는 작업을 알아보는 시간이었습니다....! 끝...!

 

 

 

[Reference]

DevOps와 MLOps과 같이 Ops로 끝나는 신규 용어들이 많이 나타나고 있는데요.

 

IT 업계에서 Ops로 끝나는 신규 용어가 많은 생기는 이유는 개발과 운영의 경계가 희석되고 협력이 필요한 현대의 소프트웨어 개발 방식에서 DevOps, MLOps, AIOps, FinOps 등 Ops로 끝나는 용어들이 많이 등장하는 것 같습니다. 또한 새로운 기술과 환경에서의 개발, 운영, 보안, 데이터 관리 등을 효과적으로 수행하기 위한 현대적인 방법론과 접근법 등을 제시하여 소프트웨어 개발 및 운영을 진행하기 위한 결과라고 생각됩니다.

 

IT 업계에서 Ops로 끝나는 신규 용어들을 한번 정리해봤습니다.

 

DevOps (Development Operations)

DevOps는 개발과 운영 팀 간의 협력을 강조하는 개발 방법론과 문화입니다. 이를 위해 자동화된 프로세스와 도구를 사용하여 소프트웨어의 빠른 개발, 안정적인 배포, 높은 품질을 실현합니다. DevOps는 조직의 협업과 지속적인 개선을 통해 비즈니스 요구에 신속하게 대응하고 소프트웨어를 효율적으로 제공합니다.

 

 

DevSecOps (Development, Security, Operations)

DevSecOps는 개발, 운영 및 보안 팀 간의 협력과 통합을 강조하는 개발 방법론 및 문화입니다. 보안을 개발 프로세스의 일부로 통합하여 소프트웨어의 보안 취약성을 최소화하고, 안정성과 신뢰성을 강화합니다. DevOps의 원칙에 보안 측면을 추가하여 조직의 비즈니스 요구에 대한 빠른 대응과 안전한 소프트웨어 개발을 실현합니다.

 

 

GitOps (Git Operations)

GitOps는 소프트웨어 배포와 인프라 운영을 Git을 통해 관리하는 개발 방법론입니다. GitOps는 코드와 인프라 상태를 Git 리포지토리에 저장하고, 변경 사항을 Git 워크플로우를 통해 자동으로 배포하고 관리합니다. 이를 통해 표준화된 배포 프로세스, 변경 추적 및 롤백 기능을 제공하여 소프트웨어 시스템을 효율적이고 일관되게 관리합니다.

 

 

MLOps (Machine Learning Operations)

MLOps는 머신 러닝 모델의 개발과 운영을 효율적으로 관리하기 위한 방법론과 프로세스입니다. MLOps는 모델 개발, 훈련, 배포, 모니터링 등의 라이프사이클을 자동화하고, 모델의 안정성, 성능, 신뢰성을 보장하기 위해 지속적인 통합과 전달, 자동화된 테스트, 버전 관리 등을 강조합니다. 이를 통해 조직은 머신 러닝 프로젝트를 효율적으로 관리하고 운영 환경에서 안정적으로 모델을 유지할 수 있습니다.

 

 

AIOps (Artificial Intelligence for IT Operations)

AIOps는 인공 지능 기술을 활용하여 IT 운영을 자동화하고 향상시키는 방법론입니다. AIOps는 대규모 데이터 분석, 자동화된 이벤트 관리, 예측 및 자가 치유 기능을 통해 장애 예방, 문제 식별 및 대응을 강화합니다. 이를 통해 조직은 IT 시스템의 가용성과 성능을 개선하고, 비즈니스 운영에 필요한 신속한 결정과 대응을 할 수 있습니다.

 

 

FinOps (Financial Operations)

FinOps는 클라우드 리소스의 비용을 효과적으로 관리하기 위한 방법론과 프로세스입니다. FinOps는 비용 추적, 예산 설정, 리소스 최적화 등을 통해 클라우드 비용을 투명하게 파악하고 최소화하는데 초점을 둡니다. 이를 통해 조직은 클라우드 리소스의 비용 효율성을 개선하고, 리소스 사용에 대한 가시성과 통제를 강화할 수 있습니다.

 

 

BizOps (Business Operations)

BizOps는 비즈니스 운영을 최적화하고 의사 결정을 지원하기 위한 방법론과 프로세스를 의미합니다. 이를 위해 데이터 분석과 비즈니스 인텔리전스를 활용하여 성과를 측정하고 개선합니다. BizOps는 조직 내 다양한 부서 간의 협력과 데이터 기반의 의사 결정을 강화하여 비즈니스 운영을 효율적으로 관리합니다.

 

 

DataOps (Data Operations)

DataOps는 데이터 관리 및 데이터 파이프라인의 효율적인 운영을 위한 방법론과 문화를 의미합니다. 데이터 수집, 전처리, 저장, 분석, 공유 등의 단계를 자동화하고 표준화하여 데이터의 품질과 가용성을 개선합니다. DataOps는 개발, 운영, 데이터 과학 등 다양한 팀 간의 협업과 지속적인 개선을 통해 데이터 주도적인 의사 결정과 비즈니스 성과 향상을 목표로 합니다.

 

 

CloudOps (Cloud Operations)

CloudOps는 클라우드 환경에서의 운영과 관리를 효율적으로 수행하기 위한 방법론과 프로세스를 의미합니다. 클라우드 서비스의 프로비저닝, 모니터링, 확장성 관리, 보안 및 비용 최적화 등을 중점으로 다룹니다. CloudOps는 클라우드 리소스의 안정성과 가용성을 유지하며, 비즈니스 요구사항에 신속하게 대응하기 위해 자동화와 표준화를 추구합니다.

 

 

ChatOps (Chat-based Operations)

ChatOps는 채팅 플랫폼을 활용하여 개발, 운영 및 협업 프로세스를 통합하는 방법론과 문화를 의미합니다. 채팅 도구를 통해 자동화된 작업 실행, 이벤트 모니터링, 협업 및 지식 공유 등을 수행하여 팀 간 커뮤니케이션과 작업 효율성을 향상시킵니다. ChatOps는 실시간 커뮤니케이션과 작업 추적을 결합하여 개발과 운영 과정을 투명하게 관리하고 자동화된 운영을 실현합니다.

 

 

SecOps (Security Operations)

SecOps는 보안 운영을 개발 및 운영 프로세스에 통합하는 방법론과 문화를 의미합니다. 개발과 운영 팀이 보안 측면에서 협력하고, 보안 사고를 예방하고 탐지하며, 대응 및 복구를 수행합니다. SecOps는 보안 요구 사항을 사전에 고려하여 시스템을 보호하고, 조직의 데이터와 인프라에 대한 안전성과 신뢰성을 강화합니다.

 

 

NetOps (Network Operations)

NetOps는 네트워크 운영을 최적화하고 관리하기 위한 방법론과 프로세스를 의미합니다. 네트워크 장비 및 구성 요소의 설치, 구성, 모니터링, 유지 보수 등을 통해 네트워크의 안정성과 성능을 유지하고 개선합니다. NetOps는 네트워크 트래픽 분석, 장애 대응, 보안 강화 등을 통해 조직의 네트워크 인프라를 효율적으로 운영하여 비즈니스 요구를 충족시킵니다.

 

 

NoOps (No Operations)

NoOps는 인프라 관리를 최소화하거나 제거하여 개발팀이 애플리케이션을 자율적으로 배포하고 관리할 수 있는 개발 방법론입니다. 클라우드 컴퓨팅, 서버리스 아키텍처 및 자동화된 운영 도구를 활용하여 인프라 관리 작업을 자동화하고 개발자 중심의 운영을 실현합니다. NoOps를 통해 조직은 더 빠른 소프트웨어 배포와 운영, 높은 효율성을 달성할 수 있습니다.

 

 

 

 

'기타' 카테고리의 다른 글

VMware OVF to OVA 변환 ovftool  (0) 2023.09.20
Windows Server 2019 WSL 설치하기  (0) 2023.04.24
VSCode 설치 및 사용법  (0) 2022.09.06
WSL2 Window 환경에서 Linux 사용하기  (0) 2022.08.23

[AWS] Insufficient capacity error 에러

AWS에서 EC2 Instance 생성 시 Insufficient capacity error from EC2 while launching instances, retrying 에러가 발생하였는데요. Insufficient capacity error 에러가 어떤 에러인지 한번 알아보도록 하겠습니다.

 

 

에러 원인

Insufficient capacity error 에러가 발생하는 이유는 AWS에서 EC2 인스턴스를 생성하려고 할 때 발생할 수 있는 일반적인 오류입니다.

이 오류는 일시적으로 해당 리전 또는 가용 영역에서 충분한 용량이 없어서 인스턴스를 생성할 수 없다는 것을 나타냅니다.

주요 원인으로는 특정 가용 영역 또는 리전의 용량 한계 도달, 대규모 인스턴스 생성 및 트래픽 발생 등이 있습니다.

 

 

해결 방법

Insufficient capacity error 에러 발생 시 아래 방법을 통해 에러를 해결 할 수 있습니다.

 

  • 다른 가용 영역 또는 리전 선택
    • 인스턴스 생성 시 다른 가용 영역 또는 리전을 선택하여 용량 부족 문제 해결할 수 있습니다.
  • 인스턴스 유형 변경
    • 인스턴스 생성 시 사용하는 인스턴스 유형을 변경하여 용량 부족 문제 해결할 수 있습니다.
    • AWS는 다양한 인스턴스 유형을 제공하므로, 특정 유형의 용량이 부족한 경우 다른 유형을 선택하여 사용할 수 있습니다
  • 스팟 인스턴스 대신 온디맨드 인스턴스 사용
    • 스팟 인스턴스는 가격이 저렴하지만 가용성은 유동적으로 스팟 인스턴스의 용량이 부족할 수 있으므로 온디맨드 인스턴스를 사용하여 인스턴스를 생성할 수 있습니다.
    • 온디맨드 인스턴스는 스팟 인스턴스보다 비용이 높지만 가용성이 더 높으므로, 즉시 인스턴스를 생성해야 할 때 유용합니다.
  • 예약 인스턴스 사용
    • EC2 예약 인스턴스는 특정 시간 동안 예약된 용량을 제공하는 인스턴스입니다.
    • 예약 인스턴스를 사용하면 인스턴스 용량을 확보하여 인스턴스를 생성하는 데 더 많은 유연성과 안정성을 가질 수 있습니다.

 

 

 

지금까지 AWS에서 Insufficient capacity error 에러 발생 시 원인 및 해결 방법에 대해 알아보는 시간이었습니다....! 끝...!

 

 

 

[Reference]

 

 

 

'AWS' 카테고리의 다른 글

[AWS] Amazon SNS 알아보기  (0) 2023.07.11
[AWS] Amazon Elastic Container Registry 알아보기  (0) 2023.06.14
[AWS] Service Quota 알아보기  (0) 2023.05.22
[AWS] AWS Summit Seoul 2023 2일차  (0) 2023.05.04
[AWS] AWS Summit Seoul 2023 1일차  (0) 2023.05.03

[AWS] Service Quota 알아보기

AWS Service Quota는 AWS 리소스 또는 서비스의 사용에 대한 제한 또는 할당량을 나타냅니다. 각 서비스에는 사용할 수 있는 리소스의 양에 대한 제한이 있을 수 있으며, 이는 예를 들어 EC2 인스턴스, S3 버킷, RDS 데이터베이스 등과 같은 리소스의 수량에 적용할 수 있습니다.

 

 


사용 시 장점

AWS Service Quota를 사용하면 리소스 및 비용 관리, 확장성, 공정한 리소스 공유 및 리소스 사용 추적과 같이 AWS 리소스를 효율적으로 활용할 수 있습니다.

 

  • 리소스 제한 관리
    • Service Quota는 사용 가능한 리소스 또는 서비스에 대한 제한을 설정하여 리소스 사용을 제어합니다.
      이를 통해 조직은 리소스의 낭비를 방지하고 예상치 못한 과부하 상황을 방지할 수 있습니다.
      제한을 통해 리소스 사용을 효율적으로 계획하고 관리할 수 있습니다.
  • 비용 관리
    • Service Quota를 사용하면 비용을 효과적으로 관리할 수 있습니다.
      제한을 설정하여 예기치 못한 추가적으로 발생하는 과금을 방지할 수 있습니다.
      리소스 사용에 대한 제한을 설정하고, 모니터링함으로써 비용을 예측하고 관리할 수 있습니다.
  • 리소스 확장 및 확장성
    • Service Quota를 사용하면 리소스 사용을 조절하고, 필요에 따라 리소스 할당량을 증가시킬 수 있습니다.
      이를 통해 비즈니스 요구에 맞추어 리소스를 확장할 수 있으며, 향후 성장에 따라 할당량을 조정할 수 있습니다.
  • 자원의 공정한 공유
    • Service Quota는 AWS 리소스를 여러 사용자 또는 팀 간에 공정하게 분배할 수 있도록 도와줍니다.
      리소스 사용을 제한함으로써 공유 리소스에 대한 공정한 액세스를 보장할 수 있습니다.
  • 리소스 사용 추적
    • Service Quota를 사용하면 리소스 사용량을 추적하고 모니터링할 수 있습니다.
      리소스 사용에 대한 제한과 함께 실시간 및 정기적인 모니터링을 통해 리소스 사용 패턴을 파악하고 최적화할 수 있습니다.

 


메뉴 및 설정 방법

AWS Management Console을 통해 Service Quota에 관한 정보와 설정을 관리할 수 있습니다.

 

Dashboard 메뉴에서는 사용 가능한 할당량, 현재 사용량, 할당량 증가 요청 및 할당량 제한에 관한 정보를 제공합니다.

 

AWS Services 메뉴에서는 AWS에서 제공하는 각 서비스에 대한 할당량과 해당 할당량의 사용 현황을 확인할 수 있으며, 요청을 통해 리소스의 제한 및 할당량을 제어할 수 있습니다.

 

AWS Services 메뉴에서 설정하고자 하는 AWS 서비스를 검색 및 선택 후 Request quota increase 버튼을 클릭합니다.

 

 

설정 값을 입력 후 Request 버튼을 통해 리소스 증가 요청을 보내게됩니다.

 

요청 처리

요청을 보내게되면 AWS Support 팀에서 요청의 적합성, 요청한 할당량 증가의 이유, 해당 리소스에 대한 가용성 등을 검토하여 승인합니다. 요청 처리 시간은 요청된 할당량 증가의 복잡성과 요청량에 따라 달라질 수 있으며 일반적으로 몇 일 이내에 처리되지만, 복잡하거나 대규모 요청의 경우 더 오랜 시간이 걸릴 수 있습니다.

 

요청의 적합성과 가용성을 평가하여 승인이 결정되며, 리소스에 대한 특정 제한 사항이나 정책에 따라 거부될 수 있습니다. 요청이 완료되면 Quota request history 메뉴에서 요청한 서비스 및 리소스 정보와 상태 정보 등을 확인하실 수 있습니다.



마지막으로 Organization - Quota request template 메뉴는 AWS Organizations을 사용하는 경우 템플릿을 통해 직의 모든 멤버 및 계정에 대한 할당량 증가 요청을 효율적으로 제출하고 관리하는 메뉴입니다.

 


리소스 제한

기본적으로 AWS Service Quota에서는 모든 리소스를 허용하고 있지 않기 때문에 아래와 같이 제한된 인스턴스 사용 시 에러가 발생할 수 있습니다. 에러를 보고 당황하지 마시고, AWS Service Quota 설정을 통해 리소스 제한 설정을 통해 정상적으로 사용하시기 바랍니다.

 

 

AWS Service Quota를 통해 자유롭고, 효율적인 AWS 리소스를 관리 해보시기 바랍니다.
지금까지 Amazon SageMaker의 AWS Service Quota가 무엇인지 알아보는 시간이었습니다....! 끝...!

 

 

 

[Reference]

 

 

 

[Ansible] Yum 패키지 관리

Ansible의 YUM 모듈은 기본 모듈 중 하나로, 리눅스 시스템에서 YUM (Yellowdog Updater, Modified) 패키지 관리자를 사용하여 패키지를 설치, 업그레이드, 제거하는 작업을 수행합니다. Ansible의 YUM 모듈을 통해 원격 호스트의 패키지 관리 작업을 자동화하여 사용할 수 있습니다.

 


YUM 모듈 구조

# 주요 매개변수 및 옵션을 사용한 예시
- name: YUM 패키지 설치, 업그레이드, 제거
  ansible.builtin.yum:
    name: package_name
    state: latest
    disable_gpg_check: true
    disablerepo: myrepo
    enablerepo: myotherrepo
    update_cache: false
    use_backend: dnf

 

주요 매개변수 및 옵션

  • name: 설치 또는 제거할 패키지의 이름을 지정합니다.
  • state: 패키지의 상태를 지정합니다.
    • present : 패키지 설치
    • latest : 최신 버전으로 패키지 업그레이드
    • absent : 패키지 제거
  • disable_gpg_check: GPG (GNU Privacy Guard) 검사를 비활성화합니다. 기본값은 False입니다.
  • disablerepo: 특정 리포지토리를 비활성화합니다.
  • enablerepo: 특정 리포지토리를 활성화합니다.
  • update_cache: YUM 패키지 캐시를 업데이트합니다. 기본값은 True입니다.
  • use_backend: 사용할 백엔드를 선택합니다. 기본 값은 auto이며, dnf 또는 yum을 직접 지정할 수도 있습니다.

 


YUM 패키지 설치

  • 실행 코드
- name: 패키지 설치
  yum:
    name: tcpdump
    state: present

 

  • 실행 로그
# ansible-playbook -i {{Inventory}}  roles/test_work.yml  -vv

TASK [test_work : 패키지 설치] *************************
changed: [node0] => {"changed": true, "changes": {"installed": ["tcpdump"]}, "msg": "##### 생략 #####", "rc": 0, "results": #####", 생략 #####", "]}

 

YUM 패키지 업그레이드

  • 실행 코드
- name: 최신 버전으로 패키지 업그레이드
  yum:
    name: tcpdump
    state: latest

 

  • 실행 로그
# ansible-playbook -i {{Inventory}}  roles/test_work.yml  -vv

TASK [test_work : 최신 버전으로 패키지 업그레이드] *****************
ok: [node0] => {"changed": false, "changes": {"installed": [], "updated": []}, "msg": "", "rc": 0, "results": ["All packages providing tcpdump are up to date", ""]}

 

YUM 패키지 제거

  • 실행 코드
- name: 패키지 제거
  yum:
    name: tcpdump
    state: absent

 

  • 실행 로그
# ansible-playbook -i {{Inventory}}  roles/test_work.yml  -vv

TASK [test_work : 패키지 제거] ************************
changed: [node0] => {"changed": true, "changes": {"removed": ["tcpdump"]}, "msg": "##### 생략 #####", "rc": 0, "results": #####", 생략 #####", "]}

 

 

기본적인 설치, 업그레이드, 제거 작업을 수행할 수 있으며 매개변수 및 옵션을 추가하여 상황에 맞는 작업을 진행할 수 있습니다. 지금까지 Ansible의 YUM 모듈을 통해서 원격 호스트의 패키지 관리 작업을 자동화하는 것을 알아보았습니다...! 끝...!

 

 

[Reference]

+ Recent posts