평소 관심있던 클라우드/인프라에 대한 지식을 습득하기에 좋은 기회라 생각되어 2024.08.10에 진행된 우분투 컨퍼런스에 참가하였다.

생각보다 대기업들의 시니어분들도 많이 참가하여 놀라웠다. NHN의 Cloud부서에서 일하고 계신 분들이 업무를 하며 마주쳤던 이슈들에 대해 얘기를 해주셨는데 개발자 사는 모습이 다 비슷비슷하구나 싶었다

Dockerfile 없어도 컨테이너 앱 빌드할 수 있어요

도커 없이 빌드하기(.NET ASP 기반)

• Docker CLI에서(대부분 언어 지원)
  • docker init (코드 분석해서 자동으로 도커 파일 만들어줌)
• DOTNET의 MSBuild는 빌드할 때 사용됨
  • dotnet publish -t:PublishContainer --os linux --arch x64
    • dll 형태가 아닌 컨테이너 형태로 만들어줌
    • 도커에 자동으로 푸시해줌
  • MSBUILDforContainer파일에서 옵션을 정의할 수 있음
  • 이미지에 환경변수도 추가가능
  • 장점은 깃액션과 같은 파이프라인상에서 빌드파일을 여러개 만들 수 있음
• 위의 방법은 C#에 한정되어 있지만, 찾아보니 외에도 java, python, node, go, rust등 다양한 언어에서 Docker 이미지 생성 도구를 찾아준다고 한다.
• 여기서 Dockerfile을 사용하는 것과 각 언어에서 지원하는 이미지 생성도구를 사용하는 것의 장단점이 궁금해졌다.
  • Dockerfile
    • 장점
      • 이미지 생성 과정에서 모든 단계를 세부적인 수준까지 핸들링 가능
      • 다양한 베이스 이미지를 선택하거나, 빌드 도구, 런타임 환경을 자유롭게 세팅 가능
      • 특정 언어나 프레임워크에 종속되지 않기에 하나의 도구로 다양한 언어와 프레임워크에 동일한 빌드 과정을 적용할 수 있음.
      • 재사용가능하고 일관된 빌드 및 배포 방식을 유지할 수 있음.
      • Dockerfile은 Docker 생태계에서 기본적으로 지원되기에 CI/CD 파이프라인, Kubernetes 같은 다양한 클라우드 플랫폼과 통합 가능함.
    • 단점
      • 이미지 레이어 최적화나 캐싱 전략 등을 고려하기가 부담됨. 잘못 관리하면 빌드 시간이 길어지거나 이미지 크기가 커질 수 있음.
      • 프로젝트 구조나 요구 사항이 자주 변경될 경우, Dockerfile을 유지보수하는 데 시간이 많이 소요될 수 있음.
      • 최적화와 보안 측면에서 고려해야 할 요소가 많음.
  • 언어별 이미지 생성 도구
    • 장점
      • Dockerfile없이도 명령어로 이미지 생성과정을 자동화 할 수 있음
      • 언어, 프레임워크에 특화되어있어 개발자가 익숙하게 사용가능함.
      • 프레임워크 별 최적화된 이미지를 생성해줌.
      • 보안 패치나 최신 라이브러리를 자동으로 적용해줌
      • 이미지를 빌드 할때 변경된 부분만 빠르게 빌드하는 피드백 루프를 제공함(이것은 도커에서도 현재 제공되는 기능)
    • 단점
      • 언어별 유연성 부족
      • 커스터마이징이 제한적임
      • 언어와 프레임워크에 종속적임
  • 즉, 빠른 개발이 필요하거나 프로젝트 구조가 자주 바뀌는 상황에서는 Dockerfile을 통한 이미지 빌드 방법보다 언어 별 지원 이미지 생성 방법을 사용하는 것이 좋고,
  • 복잡한 구조의 프로젝트 같이 여러 언어를 동시에 사용해야 하는 작업일 경우 Dockerfile을 사용하는 것이 좋다.

Ochestration

도커: Docker-compose up 이라는 명령어를 사용하여 여러 이미지를 통합

도커 컴포즈에 새로운 컨테이너를 어떻게 추가하는지?

.NET Aspire

관측용이성, 회복탄력성을 갖추게해줌 → cloud native에 필수적 요소

connection strings을 지원해줌. → aws, azure 의 key vault

Openstack의 어느 쿠버에서도 동작가능함.

언어 상관없이 지원함.

opentelemetry같은 기능이 관측용이성을 지원함.

aspire-manifest.json 파일:

도커 파일을 자동으로 만들어줌

{
  "runtime": {
    "framework": "net7.0"
  },
  "publish": {
    "output": "./publish"
  },
  "image": {
    "baseImage": "mcr.microsoft.com/dotnet/aspnet:7.0-alpine",
    "workdir": "/app",
    "entrypoint": ["dotnet", "MyApplication.dll"]
  }
}

위의 aspire-manifest.json 를 기반으로 aspire generate dockerfile 을 입력하면 Dockerfile이 자동생성됨.

NHN CLOUD OpenStack

OpenStack은 Azure같은 Cloud Infra를 구축하는 프레임워크

NHN도 Openstack 기반으로 클라우드를 구축해놓음.

최근 Terraform에도 NHN 클라우드 등록됨

Openstack은 Python으로 개발되어있음.

• 패키지 하나를 설치할 때, 의존성을 일관되게 관리하기 어려움
• Openstack에서 버전업그레이드로 해결됨
  • 우분투와 Openstack이 긴밀히 협업을 하기에 연동하기 좋음.
• pip가 의존성 지옥임 → apt만 사용하기

ubuntu로 이사하기

• 서버 os 자동 설치 도구 : dhcp + pxe boot + provisioning tool
• 기본 설치 도구도 운영체제 별로 바꿔줘야함
  • Debian preseed, Ubuntu subiquty
• rpm, pip관리 repository 서버: pulp
• pypi 관리 서버
• 결국 aptly라는 오픈소스가 채택됨
  • repo mirroring, repository publish, snapshot같은 기능들을 지원함.
• 사용자들에게 노출되는 api는 스프링기반
• 자체 개발 서비스 코드는 파이썬 기반으로
• SaltStack(ansible)을 사용하여 서버의 설정 및 서비스 파일을 관리
  • SaltStack은 Master와 Minion으로 구분됨
    • 특정 명령을 Minion에게 전달가능함(zeromq 사용 osi 7레이어에서 동작, tcp/ip 프로토콜 사용)
      • Spring의 경우 netflix eureka이 Master, Minion을 관리하는 역할,
      • Spring Cloud Config가 설정 및 서비스 파일을 관리하는 역할을 함.
  • 다양한 운영체제를 관리해야하는 경우 Saltstack을 사용,
  • MSA를 도입하려는 경우 Spring Cloud를 추천
• 파이썬의 stdeb를 사용
  • setup.py와 requirements.txt를 분석하여 debian폴더 내용을 생성해줌.
• 모든 패키지를 stdeb로 관리중.
• Unattended Upgrades(우분투 지원 자동 업그레이드 도구)
  • apt-daily: systemd-timer로 매일 apt update
    • 이때 패키지 repository를 바라봄
  • apt-daily-upgrade라는 서비스도 같이 동작함
    • 이 설정 때문에 버전 업그레이드를 해선 안되는 패키지도 버전이 변경되어서 동시 다발적으로 서버가 다운됨.
  • 옵션으로 비활성화가능 + 일부 repository만 선택가능.

Canonical Landscape

Canonical Landscape 란?:우분투 시스템 관리 자동화 도구

보안 관리, 자동 업데이트 관리

→ 여러 VM을 사용할 경우 관리가 어려움

→ 때문에 landscape를 사용

→ landscape daemon을 VM마다 설치하면 패키지중 위해성이 발견되면 콘솔에 해당 사항이 표시됨.

LXC(Linux Containers)란

• LXC는 리눅스 컨테이너 기술의 가장 기본적인 형태로, 리눅스 커널의 네임스페이스와 control groups기능을 사용하여 프로세스를 격리하고 리소스를 관리함.
  • namespace → 프로세스 격리
  • control groups → 리소스 관리
• LXC는 VM과 유사하지만, 하이퍼바이저를 사용하지 않고 운영체제 수준에서 가상화를 제공함.
  • 호스트 os의 커널을 공유하므로 리소스 효율성이 높고 속도가 빠름
  • linux 커널과 통합되어 있어 리소스 사용량은 훨씬 적지만 vm과 유사한 기능을 제공함.
  • 여러 os를 사용하지 않기에 리소스를 효율적으로 사용가능함.
• Docker의 시초에서는 LXC의 실행환경을 사용했지만, 자체 컨테이너 런타임으로 일부 전환되었음.
• 호스트 os의 커널을 직접 사용하기에 계산 집약적인 서비스, 혹은 하드웨어에 직접 액세스해야하는 애플리케이션을 실행하는데에 적합함
• ↔ 도커의 경우에는 컨테이너 단위로 격리되기에 마이크로 서비스 기반 애플리케이션에서 강력함

LXD란

LXD는 LXC(Linux Containers)를 구동하고 관리할 수 있게 해줌

편리한 인터페이스를 제공해주고, REST API로 조작이 가능함.

Tailscale을 통해 zerotrust구성가능

허브 앤 스포크 형태의 아키텍처를 가짐

스포크들은 외부에 요청을 보낼때 허브를 통해서 전달함(VPN과 동일한 기능)

종단간(end-to-end) 암호화를 지원함