Bong's Log

클라우드 환경에서 DevOps를 구현하는 방법은 다양합니다. 특히 CI/CD 파이프라인을 구축할 때 Azure DevOps, AWS DevOps, GCP DevOps와 같은 클라우드 네이티브 서비스를 사용할 수 있으며, GitLab Self-Managed와 같은 온프레미스 솔루션도 고려할 수 있습니다.

본 글에서는 각 클라우드 CI/CD 서비스의 특징과 온프레미스 GitLab 설치형 대비 장단점을 분석하고, 멀티 클라우드 전략을 선택할 경우 고려해야 할 사항에 대해 살펴보겠습니다. 또한, 아키텍트 관점에서 어떤 전략이 적절한지 논의합니다.

1. 클라우드 CI/CD 서비스 비교

(1) Azure DevOps

Microsoft의 Azure DevOps는 CI/CD, 코드 저장소, 프로젝트 관리, 빌드 및 배포 자동화를 통합 제공하는 서비스입니다.

✅ 특징:

• Azure Pipelines를 통한 강력한 CI/CD 기능
• Azure Repos (Git 저장소) 및 Azure Artifacts 제공
• Azure Boards를 활용한 프로젝트 및 애자일 관리
• 다양한 언어 및 환경 지원 (Windows, Linux, macOS, Kubernetes 등)
• GitHub 및 외부 리포지토리 연동 가능
• 온프레미스 환경에서도 Azure DevOps Server 활용 가능

⏩ 추천 대상: Azure 환경을 기반으로 DevOps를 구축하는 기업 및 조직

(2) AWS DevOps (Code Suite)

AWS는 개별 DevOps 서비스를 조합하여 CI/CD를 구성해야 합니다.

✅ 특징:

• AWS CodePipeline: CI/CD 파이프라인 자동화
• AWS CodeCommit: Git 기반 코드 저장소 (Azure Repos와 유사)
• AWS CodeBuild: 빌드 자동화 (Azure Pipelines와 유사)
• AWS CodeDeploy: EC2, Lambda, ECS 등 AWS 환경으로 배포 가능
• AWS IAM(Identity & Access Management)과 강력한 보안 연계

⏩ 추천 대상: AWS 환경에서 DevOps를 최적화하고자 하는 기업

(3) GCP DevOps

GCP는 컨테이너 중심의 CI/CD 솔루션이 강점입니다.

✅ 특징:

• Cloud Build: CI/CD 빌드 및 배포 자동화 (Jenkins 대체 가능)
• Cloud Deploy: Kubernetes 기반 애플리케이션 배포
• Artifact Registry: 컨테이너 이미지 및 패키지 저장소
• Cloud Source Repositories: Git 기반 저장소 (Azure Repos, AWS CodeCommit과 유사)
• Google Kubernetes Engine(GKE) 및 Anthos와 최적의 연동 제공

⏩ 추천 대상: Kubernetes 및 GCP 기반 마이크로서비스를 운영하는 기업

(4) GitLab Self-Managed (온프레미스)

GitLab은 Git 저장소뿐만 아니라 CI/CD, 패키지 관리, 보안 검사까지 올인원 DevOps 플랫폼을 제공합니다.

✅ 특징:

• 온프레미스 환경에서 GitLab 서버를 운영 가능 (폐쇄망에서도 사용 가능)
• GitLab CI/CD를 활용하여 빌드, 테스트, 배포 자동화 가능
• GitHub Actions, Azure Pipelines 없이 자체 CI/CD 제공
• GitLab Runner를 통해 개별 인프라에서 CI/CD 실행 가능
• 보안 및 접근 제어 기능 강화 (RBAC, SAML, LDAP 지원)

⏩ 추천 대상: 폐쇄망 환경에서 DevOps가 필요한 기업 및 자체 관리형 Git 솔루션을 원하는 조직

2. 멀티 클라우드 전략을 고려할 경우

멀티 클라우드 환경에서는 한 가지 클라우드 플랫폼에 종속되지 않고, 다양한 클라우드 서비스를 조합하여 사용합니다. 이를 위한 DevOps 전략도 변화해야 합니다.

✅ 멀티 클라우드 DevOps 구축 시 고려할 점

1. CI/CD 파이프라인의 일관성 유지
   • 각 클라우드 서비스의 CI/CD를 개별적으로 운영하면 관리가 어려워질 수 있음
   • GitLab CI/CD 또는 Jenkins 같은 클라우드 독립적인 CI/CD 솔루션을 고려해야 함
2. 공통 코드 저장소 활용
   • GitHub, GitLab.com 같은 중앙화된 리포지토리를 사용하면 멀티 클라우드 환경에서도 일관된 소스 코드 관리 가능
3. 보안 및 네트워크 정책 검토
   • 온프레미스 환경과 클라우드 간 데이터 이동 시 보안 정책 고려 필요
   • CI/CD 실행 환경을 폐쇄망과 연계할 경우, GitLab Self-Managed 같은 솔루션이 적합할 수 있음
4. 배포 환경 최적화
   • AWS, Azure, GCP의 배포 방식이 다르므로 Kubernetes, Terraform 등을 활용하여 인프라를 자동화하는 것이 필요

3. 결론 및 추천 전략

🚀 선택 기준 정리

선택 기준추천 플랫폼

💡 멀티 클라우드 환경에서는 특정 클라우드에 종속되지 않는 GitLab CI/CD, Jenkins, ArgoCD 같은 범용 DevOps 툴을 고려하는 것이 유리하다.

아키텍트 입장에서 각 클라우드별 CI/CD를 활용할지, GitLab Self-Managed와 같은 독립적인 솔루션을 선택할지를 결정하는 것은 보안, 확장성, 관리 편의성을 기준으로 최적의 방법을 찾아야 합니다.

1. 서론

로컬에서 개발한 프로젝트를 GitHub에 올려서 원격 저장소에서 관리하는 방법을 알아봅니다. GitHub는 버전 관리와 협업을 위한 중요한 도구로, 프로젝트를 원격에서 안전하게 관리할 수 있게 해줍니다. 이 글에서는 로컬 Git 저장소를 GitHub에 연결하고, 소스 코드를 푸시하는 방법을 단계별로 안내합니다.

2. Git 설치 확인하기

GitHub에 프로젝트를 올리기 전에, 먼저 Git이 로컬에 설치되어 있는지 확인해야 합니다. 터미널 또는 명령 프롬프트에서 아래 명령어를 입력하여 Git이 설치되어 있는지 확인할 수 있습니다.

설치된 Git 버전이 출력되면, Git이 정상적으로 설치된 것입니다. 만약 "command not found" 또는 유사한 메시지가 나타난다면, (https://git-scm.com/)에서 Git을 설치한 후 다시 시도하세요.

3. 로컬 Git 저장소 초기화하기

GitHub에 프로젝트를 푸시하려면, 먼저 로컬 프로젝트에서 Git 저장소를 초기화해야 합니다. 프로젝트 디렉토리에서 다음 명령어를 실행합니다.

이 명령어는 해당 폴더를 Git 저장소로 설정합니다. 이제 로컬 저장소에서 Git을 사용할 준비가 되었습니다.

4. GitHub에서 Repository 생성하기

GitHub에서 새 저장소를 만들어야 합니다. GitHub에 로그인한 후, + 버튼을 클릭하고 **"New repository"**를 선택합니다. 이후 Repository name을 입력하고 Create repository를 클릭합니다. 새로 생성된 GitHub 저장소의 HTTPS URL을 복사합니다.

5. 원격 저장소 연결하기

로컬 Git 저장소와 GitHub 저장소를 연결하려면, GitHub에서 복사한 원격 저장소 URL을 사용합니다. 터미널에서 아래 명령어를 실행하세요:

이제 로컬 저장소는 GitHub의 원격 저장소와 연결되었습니다.

6. 변경 사항 추가 및 커밋하기

로컬에서 변경한 파일을 Git에 추가하고 커밋합니다. 변경된 파일을 모두 추가하려면 git add . 명령어를 사용하고, 커밋 메시지를 입력하여 커밋을 완료합니다.

7. GitHub에 푸시하기

로컬 저장소의 내용을 GitHub에 푸시하려면, 아래 명령어를 실행하여 원격 저장소에 파일을 업로드합니다.

1. 서론

GitHub에 프로젝트를 올릴 때, 임시 파일이나 빌드 파일 등 불필요한 파일들이 함께 올라가는 경우가 많습니다. 이런 파일들은 프로젝트에 필요하지 않으며, GitHub의 저장소 공간을 차지할 뿐만 아니라 협업 시 불필요한 혼란을 초래할 수 있습니다. 이 문제를 해결하는 방법은 바로 .gitignore 파일을 활용하는 것입니다.

2. .gitignore란?

.gitignore 파일은 Git에게 어떤 파일을 추적하지 않을지 지정하는 설정 파일입니다. 이 파일을 사용하면, 특정 폴더나 파일을 Git의 버전 관리에서 제외시킬 수 있습니다. 이를 통해 프로젝트에 불필요한 파일이 GitHub에 올라가지 않도록 할 수 있습니다.

3. .gitignore 파일 생성하기

프로젝트 루트 디렉토리에서 .gitignore 파일을 생성한 후, 제외할 파일들을 지정합니다. 예를 들어, Gradle을 사용하는 경우 build/나 .gradle/ 같은 파일들이 불필요하게 포함될 수 있습니다. 이를 .gitignore에 추가하려면 다음과 같은 내용으로 파일을 작성하면 됩니다.

4. 이미 Git에 추가된 파일 제거하기

.gitignore 파일을 추가하더라도 이미 Git에 추가된 파일들은 계속 추적될 수 있습니다. 이 경우, git rm --cached 명령어로 Git에서 해당 파일들을 제거해야 합니다.

git rm -r --cached .gradle
git rm -r --cached build

5. 변경 사항 커밋하고 푸시하기

이제 .gitignore 파일을 추가하고 불필요한 파일을 제거한 후, 변경 사항을 커밋하고 GitHub에 푸시하면 됩니다.

git add .gitignore
git commit -m "Add .gitignore to exclude Gradle files"
git push origin master

6. 결론

.gitignore 파일은 Git과 GitHub에서 효율적인 버전 관리를 위해 꼭 필요한 도구입니다. 프로젝트의 불필요한 파일들을 제외시킴으로써, 저장소가 깔끔해지고 협업이 원활해집니다. 이제 GitHub에 파일을 푸시할 때마다 .gitignore를 활용하여, 필요한 파일만 관리할 수 있게 되었습니다.

최근 Docker를 활용한 이미지 배포와 클라우드 환경에서의 VM 구축 경험을 통해, 인프라 및 미들웨어 설정이 얼마나 간소화되었는지 체감하고 있습니다. 이전보다 훨씬 수월하게 개발 및 배포 환경을 구성할 수 있게 된 덕분에, 이번 프로젝트에서는 **기본 인프라(혹은 인프라 기반)**를 탄탄하게 만든 후, 실제 서비스 구동에 필요한 웹 서비스 환경을 구축해보려고 합니다.

프로젝트 개요

이번 프로젝트의 주요 목표는 다음과 같습니다.

• 인프라 구성:
  • GCP 혹은 Azure의 무료 티어를 활용하여 VM을 생성합니다.
  • 해당 VM 위에 Docker를 설치해 컨테이너 기반 환경을 구축합니다.
• 서비스 구성:
  • Docker 컨테이너 내에서 nginx와 tomcat을 활용해 웹 서비스를 운영합니다.
  • 백엔드는 Spring Boot, 프론트엔드는 React를 사용하여 개발합니다.
• CI/CD 파이프라인 구축:
  • 개인 GitHub 저장소를 이용해 코드 관리를 하고, 이를 통해 CI(Continuous Integration)를 구성합니다.
  • GitLab과 같은 다른 CI 도구도 고려해봤지만, 서버 리소스 사용량이 많아 클라우드 환경에 부적합하다고 판단하여 GitHub 방식으로 진행할 예정입니다.

Docker로 인프라 구축하기

Docker를 도입하면서부터 인프라 관련 설정이 크게 간소화된 것을 느낍니다.
기존에는 직접 VM에 서버 설정을 하고, 필요한 미들웨어를 하나하나 설치하며 시간을 많이 소비했지만, 이제는
Docker 이미지로 배포를 통일하여 빠르고 일관된 환경 구성이 가능해졌습니다.

예를 들어, Nginx와 Tomcat을 각각 컨테이너로 운영한다면, 다음과 같은 장점이 있습니다.

• 일관성:
  개발 환경과 운영 환경의 차이를 줄일 수 있습니다.
• 유연성:
  컨테이너 단위로 손쉽게 배포 및 스케일 아웃할 수 있습니다.
• 효율성:
  리소스 사용 최적화와 빠른 배포가 가능합니다.

웹 서비스 구현 기술 스택

프로젝트의 서비스 부분은 상대적으로 가장 익숙한 환경인 Spring Boot와 React를 활용할 예정입니다.
이 조합은 백엔드와 프론트엔드 모두 빠르게 개발할 수 있는 강력한 도구임은 물론,
다양한 커뮤니티 자료와 템플릿 덕분에 초반 개발 부담을 줄이는 데 도움이 됩니다.

무료 웹 템플릿, 어디서 구하지?

프론트엔드 쪽은 전문성이 깊지 않기 때문에, 무료로 사용할 수 있는 웹 템플릿 제공 사이트가 있다면 큰 도움이 될 것 같습니다.
우선은, 아래의 사이트를 참고할 예정이고 다음에 무료 리소스 관련 정리를 추가로 하려합니다.

• Start Bootstrap:
  Bootstrap 기반의 다양한 무료 템플릿을 제공하여, 빠른 프로토타이핑에 유용합니다.
• HTML5 UP:
  현대적이고 세련된 디자인의 템플릿들을 무료로 제공합니다.
• Colorlib:
  여러 가지 카테고리의 무료 HTML 템플릿을 다운로드할 수 있습니다.
• FreeHTML5.co:
  다양한 레이아웃과 디자인의 템플릿을 무료로 제공합니다.

이 외에도 여러 무료 리소스들이 있으니, 자신의 프로젝트 스타일에 맞는 템플릿을 찾아보시면 좋겠습니다.

CI/CD와 GitHub를 통한 배포 전략

초기에는 GitLab을 통한 CI/CD 구축을 고려했지만, 서버 리소스 사용량이 예상보다 많아 클라우드 환경에 적합하지 않을 수 있다는 판단 하에, 개인 GitHub 저장소를 통해 코드를 관리하고 clone하여 배포하는 방식을 택할 예정입니다.

이 방식은 다음과 같은 이점이 있습니다.

• 경량화:
  클라우드 자원의 효율적 사용이 가능합니다.
• 유연성:
  개인 저장소를 통해 손쉽게 코드 배포 및 버전 관리를 할 수 있습니다.
• 확장성:
  추후에 필요시 다른 CI/CD 도구로의 전환도 고려할 수 있습니다.

앞으로의 계획

이번 글에서는 전체 프로젝트의 개요와 주요 목표, 그리고 사용 기술 스택에 대해 소개드렸습니다.
앞으로는 각 구성 요소에 대해 더 구체적인 내용과 설정 방법, 배포 전략 등을 하나씩 상세하게 다루는 글들을 연재할 계획입니다.

1. 인프라 설정: GCP/Azure의 무료 티어 VM 구축 및 Docker 설치
2. 컨테이너 구성: nginx와 tomcat Docker 컨테이너 구성 방법(혹은 Jenkins와 같은 CI도구까지)
3. 웹 서비스 개발: Spring Boot와 React를 이용한 기본 서비스 구현
4. CI/CD 파이프라인 구축: GitHub를 활용한 자동화 배포 전략

프로젝트 진행 과정에서 얻은 경험과 팁들을 공유하면서, 비슷한 고민을 하고 계신 분들께 도움이 될 수 있기를 바랍니다.

도커(Docker)는 컨테이너 기반 가상화 기술로, 개발 환경을 구축하고 애플리케이션을 배포하는 데 필수적인 도구입니다. 도커를 사용하려면 여러 가지 명령어를 익혀야 하며, 특히 이미지 관리, 컨테이너 실행, 빌드 및 시스템 관리 관련 명령어는 실무에서 자주 사용됩니다.

이 글에서는 도커를 사용할 때 반드시 알아야 할 주요 명령어들을 정리하고, docker run 명령어의 다양한 옵션까지 함께 살펴보겠습니다.

1. 이미지 관련 명령어

도커의 이미지는 컨테이너를 실행하는 데 필요한 모든 요소(코드, 런타임, 라이브러리 등)를 포함하고 있습니다.

• 이미지 목록 확인:
  docker images
  docker image ls
• 이미지 검색:
  docker search <이미지 이름>
• 이미지 다운로드(Pull):
  docker pull <이미지명:태그>
• 이미지 삭제:
  docker rmi <이미지 ID 또는 이름>
• 사용하지 않는 이미지 정리:
  docker image prune

2. 컨테이너 관련 명령어

도커 컨테이너는 실행 중인 애플리케이션의 인스턴스입니다. 컨테이너를 생성, 실행, 중지하는 명령어들을 살펴봅니다.

• 컨테이너 생성 및 실행:
  docker run <옵션> <이미지명>
• 실행 중인 컨테이너 목록 확인:
  docker ps
• 모든 컨테이너 목록(중지된 컨테이너 포함) 확인:
  docker ps -a
• 컨테이너 중지:
  docker stop <컨테이너 ID>
• 컨테이너 시작:
  docker start <컨테이너 ID>
• 컨테이너 재시작:
  docker restart <컨테이너 ID>
• 컨테이너 삭제:
  docker rm <컨테이너 ID>

3. docker run의 주요 옵션 정리

docker run 명령어는 컨테이너를 실행할 때 사용하는 가장 중요한 명령어 중 하나입니다. 다양한 옵션을 활용하면 컨테이너 실행 방식을 세밀하게 제어할 수 있습니다.

4. 빌드 및 기타 명령어

• Dockerfile을 사용해 이미지 빌드:
  docker build -t <이미지명:태그> <Dockerfile 경로>
• 컨테이너를 이미지로 저장:
  docker commit <컨테이너 이름> <새 이미지명>
• 도커 버전 확인:
  docker version
• 도커 시스템 정보 확인:
  docker info

마무리

위에서 정리한 명령어들은 도커를 사용할 때 가장 기본적이면서도 필수적인 기능들입니다. 컨테이너 환경을 더욱 효율적으로 관리하려면 각 명령어의 다양한 옵션을 이해하고 활용하는 것이 중요합니다.

다음 글에서는 Docker Pointainer 같은 GUI 툴 활용법과 메모리 제한, 네트워크 설정 등 컨테이너 최적화 기법을 다뤄보겠습니다.

1. 개요

GitLab CE(Community Edition)는 Git 리포지토리 관리 및 CI/CD 기능을 제공하는 강력한 도구입니다. Ubuntu 22.04에서 Docker를 사용하여 최신 GitLab CE를 설치하고, root 계정의 비밀번호를 초기화하는 과정을 정리하겠습니다.

2. GitLab CE Docker 컨테이너 설치

2.1. Docker 설치 (미설치 시)

2.2. GitLab CE 컨테이너 실행

아래 명령어를 실행하여 최신 GitLab CE를 컨테이너로 배포합니다.

명령어 설명:

• --hostname gitlab.example.com → GitLab의 도메인 지정 (변경 가능)
• --publish 80:80, 443:443, 2222:22 → HTTP, HTTPS, SSH 포트 설정
• --name gitlab → 컨테이너 이름을 gitlab으로 설정
• --restart always → 서버 재부팅 시 자동 시작
• /data/gitlab/config, /data/gitlab/logs, /data/gitlab/data → 데이터 유지용 볼륨 설정

컨테이너 실행 상태를 확인합니다.

3. GitLab root 계정 비밀번호 초기화

GitLab 설치 후, root 계정의 초기 비밀번호를 찾거나 변경해야 합니다.

3.1. 초기 비밀번호 확인

설치 후 GitLab은 /etc/gitlab/initial_root_password에 임시 비밀번호를 저장합니다.

위 파일이 존재한다면, 해당 비밀번호를 사용하여 로그인합니다.

3.2. 비밀번호 재설정 (초기 비밀번호 분실 시)

root 계정의 비밀번호를 초기화하려면 다음 단계를 수행합니다.

1. GitLab 컨테이너에 접속
    

   docker exec -it gitlab bash
2. GitLab Rails 콘솔 실행
    

   gitlab-rails console -e production
3. oot 계정 비밀번호 변경
   user = User.find_by(username: 'root')

   user.password = '새로운비밀번호'

   user.password_confirmation = '새로운비밀번호'

   user.save!
4. 콘솔 종료 후 컨테이너 재시작
   exit

   docker restart gitlab

4. GitLab 접속 및 초기 설정

설치가 완료되면 웹 브라우저에서 GitLab에 접속합니다.(http://<서버IP>)

로그인 후 사용자 계정을 추가하고 기본 설정을 진행하면 GitLab을 사용할 준비가 완료됩니다.

처음엔 그냥 GCP VM에 Docker를 설치하고, GitLab까지 올리면 끝날 줄 알았다. 하지만 예상과 다르게 메모리 부족, 디스크 부족이라는 현실이 기다리고 있었다. 겨우 해결했다고 생각했는데, VM을 재부팅하니 NAS 마운트가 풀려있었다...

이번 글에서는 GCP VM에서 메모리를 증설하고, 디스크를 마운트하는 과정 그리고 NAS 마운트를 부팅 시에도 유지하는 방법을 시행착오와 함께 정리해보려고 한다.

1. GCP VM에서 Docker & GitLab 설치 후 자원 부족 문제

GitLab 설치 후 메모리 부족 발생

GitLab을 설치한 후 실행하는데, OOM(Out of Memory) 오류가 발생했다.
로그를 확인해보니 메모리가 부족해서 프로세스가 종료되는 상황이었다.

(VM에 접속이 안되던 경우가 잦았는데 메모리 부족이 원인이었던듯..)

해결: VM 메모리 증설

메모리를 늘리려면 GCP에서 인스턴스 유형을 변경해야 한다.
GCP 콘솔에서 다음 경로로 이동했다.

Compute Engine → VM 인스턴스 → 해당 VM 클릭 → 수정

여기서 머신 유형을 업그레이드하고, 메모리를 늘린 뒤 저장하면 끝!
하지만, VM을 멈추고 변경해야 하는 점을 기억하자.

터미널에서 직접 변경하려면 다음 명령어를 사용할 수도 있다.

이제 다시 실행해보니 GitLab이 정상적으로 동작했다.

2. 디스크 부족 해결: 새로운 디스크 추가 후 마운트

GitLab이 정상 동작하는 듯했지만, 이번에는 디스크 용량 부족 문제가 터졌다.

추가로 설치할 것이 많아서, 추가 디스크를 연결하기로 했다.

새로운 디스크 생성 및 VM에 연결

1. GCP 콘솔에서 Compute Engine → 스토리지 → 디스크 → 새 디스크 생성
2. 기존 VM과 같은 존(zone) 선택
3. 적절한 크기(예: 100GB) 설정 후 저장

이제 이 디스크를 VM에 마운트해야 한다.

3. NAS 마운트 유지하기 (재부팅 후에도 유지되게 설정)

디스크까지 마운트하고 나서 안심했지만, VM을 재기동하니 NAS 마운트가 풀려 있었다.
GitLab 데이터 저장을 위해 NAS를 연결했는데, 부팅 후 다시 마운트해야 하는 문제가 발생했다.

수동 NAS 마운트 방법

sudo mount /dev/sdb /data/gitlab_data # 디스크 마운트

해결: /etc/fstab에 NAS 마운트 추가

자동 마운트를 위해 /etc/fstab에 다음 내용을 추가했다.

sudo blkid #디스크 UUID 확인
nano /etc/fstab

UUID=0c0216-****************-************** /data xfs default 0 2

sudo mount -a # 설정적용확인

사용자마다 /etc/fstab 내용은 다를 수 있다. 기본으로 입력되어 있는 정보들은 잘 못 건드리면 부팅이 안될 수도 있으니 건드리지 말고, 마지막 줄에 mount 하고자 하는 내용을 입력하면 된다.

마지막에 숫자 0 2 의 의미는 각각 dump 생성 여부 / fsck 실행 순서를 나타내는데, 잘 모르겠다면 0, 2 로 셋팅하면 되는거 같다.

마무리

이번 삽질(?)을 통해 다음과 같은 교훈을 얻었다.

1. GitLab은 메모리를 많이 먹으므로 충분한 메모리를 확보할 것.(비용을 고려하면,  다른 형상관리 및 CI/CD를 사용하는것도..)
2. 디스크가 부족하면 VM에 새로운 디스크를 추가하고 자동 마운트를 설정할 것.
3. NAS 마운트가 풀리는 문제는 /etc/fstab에 옵션을 추가해 해결할 것.

이제 GCP에서 GitLab을 안정적으로 운영할 수 있게 되었다.
혹시라도 같은 문제를 겪는 분들에게 도움이 되었으면 좋겠다!

이번 글에서는 GCP VM을 생성하고 Docker를 설치하는 과정을 정리해보려고 한다.

1. GCP에서 VM 인스턴스 생성

먼저, GCP 콘솔에서 새로운 VM을 생성한다.

• Compute Engine → VM 인스턴스 → 새 인스턴스 만들기
• Ubuntu LTS 버전 선택 (Ubuntu 22.04 사용)
• 방화벽에서 HTTP, HTTPS 트래픽 허용 체크

설정을 마치고 생성 버튼을 누르면 VM이 만들어진다.

2. SSH로 접속하기

VM이 생성되면 SSH로 접속해야 한다. GCP 콘솔에서 바로 연결할 수도 있고, 로컬 터미널에서 SSH를 사용할 수도 있다.

접속 후 바로 업데이트부터 해준다.

3. Docker 설치

이제 Docker를 설치해보자. 공식 문서를 따라 하면 쉽게 될 줄 알았지만, 몇 가지 추가 설정이 필요했다.

1) Docker 패키지 설치

sudo apt install -y docker.io

2) 서비스 시작 및 활성화

3) 현재 사용자에게 Docker 권한 부여

Docker 명령어를 실행할 때마다 sudo를 붙이기 귀찮다면 현재 사용자를 docker 그룹에 추가하자.

변경 사항을 적용하려면 로그아웃 후 다시 로그인하거나, 다음 명령어를 실행한다.

이제 docker ps 같은 명령어를 sudo 없이 사용할 수 있다.

4. Docker 정상 작동 확인

Docker가 정상적으로 설치되었는지 확인해보자.

마무리

GCP에서 VM을 생성하고 Docker를 설치하는 과정은 간단해 보이지만, 직접 해보면 예상치 못한 문제들이 발생할 수 있다. 다음에는 VM에 NAS를 mount하는 방법과 Docker 명령어를 정리해보도록 하겠다.