대충 아래와 같이 체크리스트를 만들어봤습니다.

물론 지금당장 할건아니고 하나씩 공부해보면서 해볼려고합니다.

체크리스트

네트워크 보안:

클러스터 내의 모든 네트워크 트래픽이 암호화되어 있나요? 외부에서의 액세스는 허용되지 않도록 네트워크 정책이 적절히 설정되어 있나요?

인증과 권한 부여:

클러스터 내에서 사용자와 서비스 계정에 대한 적절한 인증 수단이 구성되어 있나요? RBAC(Role-Based Access Control)이 활성화되어 있으며, 필요한 권한만을 부여하고 있는지 확인하셨나요?

TLS(Transport Layer Security) 사용:

모든 클러스터 컴포넌트 간의 통신은 TLS를 사용하여 암호화되고 있나요?

etcd 보안:

etcd는 안전한 인증 및 통신 방법을 사용하고 있나요? 불필요한 접근을 막기 위한 etcd 접근 제어가 설정되어 있나요?

Pod 보안:

Pod의 보안 컨텍스트와 리소스 요구 사항이 적절히 설정되어 있나요? 컨테이너 이미지는 안전한 소스에서 가져온 것인가요?

시스템 업데이트:

클러스터의 모든 컴포넌트 및 운영 체제는 최신 상태인가요?

로그 및 감사:

클러스터에서 발생하는 로그는 적절히 수집되고 분석되고 있나요? 보안 이벤트에 대한 감사가 활성화되어 있나요?

신규 사용자 대상으로 약 3달동안 300$의 이용료를 제공해준다!

서버요구사항

• CPU : 4 Core (권고)
• Memory : 16GB (최소) / 32GB(권고)
• 방화벽 (필수) : 27015~27016 (TCP/UDP), 8211 (UDP)
• 방화벽 (권고) : 25575 (TCP/UDP) ⇒ RCON

구글 클라우드 VM 배포

시작전

💡 Tips :

1. 구글 클라우드에 회원가입하면 3달간 300$가 충전됩니다.
2. 충전된 금액을 모두 소진하거나, 3달이 지나면 유료 회원 전환 여부를 물어 봅니다.
3. 유료 회원으로 전환하지 않으면 모든 자원은 구글에서 회수하고, 비용이 청구되지 않습니다.
4. 클라우드 구축은 포트포워딩이 필요 없으며, 종료하지 않는이상 IP가 바뀌지 않습니다.

1. VM 인스턴스 생성

먼저 서버를 구동시킬 VM 인스턴스를 생성해보자.

리전과 영역

리전과 영역은 사용자의 목적에 따라 설정하시면되는데 대부분 한국에서 사용할것이니 리전은 서울로 영역은 본인의 취향에 맞게 추가하면됩니다.

머신구성

권장사항을 충족하기 위해 N2 시리즈 중 standard-4 이상을 선택하시면됩니다. (N2는 Intel, N2D는 AMD 입니다)

부팅 디스크

운영체제 -> Ubuntu 버전 -> 22.04 LTS x86 (AMD는 ARM64) 크기 -> 15GB (추후 업데이트 대비)

그 외에 옵션은 기본으로 두고 인스턴스 생성하시면 됩니다.

VPC 설정

Default VPC 방화벽 설정

아래의 포트를 허용시켜줍시다.

tcp:27015 tcp:27016 tcp:25575 udp:27015 udp:27016 udp:25575 udp:8211

이후 콘솔에서 SSH 접속을 통해 OS 설정을 진행하자

OS 방화벽 개방

• 진행전 OS Update를 하자
  apt update

• 방화벽 개방 명령어 실행

    sudo iptables -I INPUT -p tcp --dport 27015 -j ACCEPT
    sudo iptables -I INPUT -p tcp --dport 27016 -j ACCEPT
    sudo iptables -I INPUT -p tcp --dport 25575 -j ACCEPT
    sudo iptables -I INPUT -p udp --dport 27015 -j ACCEPT
    sudo iptables -I INPUT -p udp --dport 27016 -j ACCEPT
    sudo iptables -I INPUT -p udp --dport 25575 -j ACCEPT
    sudo iptables -I INPUT -p udp --dport 8211 -j ACCEPT
  
    sudo iptables -S         <- 설정 저장

• 방화벽 개방 확인

    sudo iptables -nL
  
    ### 방화벽 개방 확인 ###
  
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:8211
    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:25575
    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:27016
    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:27015
    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25575
    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:27016
    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:27015

게임 엔진 설치

• Steam 설치
  Steam CMD install sudo add-apt-repository multiverse; sudo dpkg --add-architecture i386; sudo apt update sudo apt install steamcmd

• GameEngine 설치

    steamcmd +login anonymous +app_update 2394010 validate +quit

• SDK64 설치

    mkdir -p ~/.steam/sdk64/
    steamcmd +login anonymous +app_update 1007 +quit
    cp ~/Steam/steamapps/common/Steamworks\ SDK\ Redist/linux64/steamclient.so ~/.steam/sdk64/

• Initial 실행 (최초 1회 실행)

    ## 게임 설치 디렉토리로 이동 ##
    cd ~/Steam/steamapps/common/PalServer
  
    ## 구동기 실행 ##
    ./PalServer.sh

• 서버 설정 파일 수정 (커스터마이징)

• 상세한 서버 옵션 설정은 개발사 홈페이지 참조 : 클릭링크이동

    vi ~/Steam/steamapps/common/PalServer/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini 

    **## 아래 부분을 사용자의 환경에 맞추어 수정후 PalWorldSetting.ini 파일에 적용합니다 ##**
  
    [/Script/Pal.PalGameWorldSettings]
    OptionSettings=(Difficulty=None,DayTimeSpeedRate=1.000000,NightTimeSpeedRate=1.000000,ExpRate=1.000000,PalCaptureRate=1.000000,PalSpawnNumRate=1.000000,PalDamageRateAttack=1.000000,PalDamageRateDefense=1.000000,PlayerDamageRateAttack=1.000000,PlayerDamageRateDefense=1.000000,PlayerStomachDecreaceRate=1.000000,PlayerStaminaDecreaceRate=1.000000,PlayerAutoHPRegeneRate=1.000000,PlayerAutoHpRegeneRateInSleep=1.000000,PalStomachDecreaceRate=1.000000,PalStaminaDecreaceRate=1.000000,PalAutoHPRegeneRate=1.000000,PalAutoHpRegeneRateInSleep=1.000000,BuildObjectDamageRate=1.000000,BuildObjectDeteriorationDamageRate=1.000000,CollectionDropRate=1.000000,CollectionObjectHpRate=1.000000,CollectionObjectRespawnSpeedRate=1.000000,EnemyDropItemRate=1.000000,DeathPenalty=All,bEnablePlayerToPlayerDamage=False,bEnableFriendlyFire=False,bEnableInvaderEnemy=True,bActiveUNKO=False,bEnableAimAssistPad=True,bEnableAimAssistKeyboard=False,DropItemMaxNum=3000,DropItemMaxNum_UNKO=100,BaseCampMaxNum=128,BaseCampWorkerMaxNum=15,DropItemAliveMaxHours=1.000000,bAutoResetGuildNoOnlinePlayers=False,AutoResetGuildTimeNoOnlinePlayers=72.000000,GuildPlayerMaxNum=20,PalEggDefaultHatchingTime=72.000000,WorkSpeedRate=1.000000,bIsMultiplay=False,bIsPvP=False,bCanPickupOtherGuildDeathPenaltyDrop=False,bEnableNonLoginPenalty=True,bEnableFastTravel=True,bIsStartLocationSelectByMap=True,bExistPlayerAfterLogout=False,bEnableDefenseOtherGuildPlayer=False,CoopPlayerMaxNum=4,ServerPlayerMaxNum=**32**,ServerName="**Default Palworld Server**",ServerDescription="",AdminPassword="**12341234**",ServerPassword="",PublicPort=8211,PublicIP="",RCONEnabled=False,RCONPort=25575,Region="",bUseAuth=True,BanListURL="https://api.palworldgame.com/api/banlist.txt")

• 설정파일 적용 확인

    cat ~/Steam/steamapps/common/PalServer/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini 

서버 최종 구동

• 게임 실행 : Screen Utility 실행

    screen

• 게임실행 : PALWORLD 실행

    ## 게임 디렉토리로 이동 ##
    cd ~/Steam/steamapps/common/PalServer
  
    ## 게임 구동기 실행 ##
    ./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

• screen 유틸리티 백그라운드로 돌려 놓고 나가기

    ctrl + a + d 

번외 사항 :

• 나중에 다시 Screen 화면으로 돌아가고 싶을때

    screen -r 

  • 추후 Trial이 만료되면 데이터 마이그레이션을 통해 동일하게 진행하시면됩니다.

참고자료

제작에 참고한 자료들

• (공식) Palworldgame docs (영어) : https://tech.palworldgame.com/dedicated-server-guide
• 유튜브 채널 테크팀(Tech Tim)

1. 기술 스택 선정 이유:

Terraform

많은 회사에서 IaC를 통한 인프라 프로비저닝을 하기때문에 경험해 보는것도 도움이 될거라 생각했고 그 중에서도 Terraform을 선정한 이유는 높은 퍼블릭 클라우드 서비스와의 호환성과 교육과정을 진행하며 접해봤던 IaC 스택 중 하나 였기 때문이다.

AWS

프라이빗 클라우드로 온프레미스 환경에서 인프라를 구축하려고 했지만 교육시설의 공인 IP 할당 한계로 인하여 퍼블릭 클라우드를 사용하게 되었고 그 중 에서도 AWS를 사용한 이유는 현재 전세계에서 가장 많이 사용하는 퍼블릭 클라우드 서비스이며 또한 전파진흥협회에서 AWS 비용을 지원해준다고하여 사용하게 되었다. 그렇다고 AWS의 모든 서비스를 활용하는것이 아닌 최대한 오픈소스를 활용하는 방안으로 프로젝트를 진행하기로했다.

GitOps

개발자 관점에서 기존에 사용하고 있던 Git Repository에서 형상 관리하던 방식 그대로 사용하기만 해도 실제 환경에 배포가 가능하며, 배포 결과를 즉시 확인하고 보다 나은 방식을 다시 적용할 수 있어 Jenkins, Argo CD를 활용한 Gitops 방식을 사용하게 되었습니다.

아래는 저희 프로젝트에서 사용한 파이프라인입니다.

Gitlab에서의 Push가 이루어졌을때 발생한 Webhook을 Jenkins에 전달하여 이미지를 빌드한뒤 Docker harbor의 Repository에 저장이 되고 성공적으로 빌드가 이루어지면 ArgoCD에 배포 이벤트를 전송하며 Git Repository에 정의된 매니페스트를 통해 클러스터에 배포가 이루어집니다

Monitoring

멀티리전을 통한 가용성 보장한 인프라이므로 Route53 트래픽 전환을 위해 AWS의 CloudWatch을 사용해야 했지만 오픈소스를 최대한 활용하는게 능력을 기르는데에 좋을거같아 클러스터의 모니터링은 Prometheus + Grafana를 이용하여 모니터링 시스템을 구축하였습니다.

추후에 ELK, EFK를 활용한 로그와 이벤트 데이터 시각화도 추가하였습니다. 요기있습니다.

2. Architecture 구성

Bastion Host

개발자들의 입장을 고려하여 기존의 환경과 동일하게 Git Push가 가능하게끔 Bastion Host를 두었습니다. VPN을 사용하여 더욱 안전한 환경에서 프로젝트를 진행하면 좋았겠지만 비용, 예산상의 문제로 Public Subnet에 Bastion Host를 두었습니다.

EKS

3개의 AZ에 각각 Master Node가 위치하게끔 클러스터를 구성하였으며 NAT GateWay를 통해 외부로의 접속이 가능하게끔 하였습니다.

RDS

각 리전별로 1개의 RDS를 두고 클러스터링을 통해 연동을 시켰습니다.

Route53

사전 구매한 도메인을 활용하여 AWS의 Route53과 연동시킨뒤 Nginx Ingress Controller를 통하여 로드밸런싱을 진행하였습니다. 또한 리전별로 Health Check를 진행하여 트래픽을 분산, 전환하였습니다.

Cloud Watch

서비스 중단, 임계값 임박 등 상황에 도달하면 경보를 발생시키며 Route53의 트래픽 전환의 기준이 됩니다.

3. 보완사항

3-1. Terraform을 어디까지 사용해야 하나?

• 테라폼의 한계로 인하여 상세한 설정 불가로 기준을 확실히 하고 프로젝트를 진행하였으면 서비스에 더욱 집중할 시간이 많지 않았을까 라는 아쉬움이 남는다.

3-2. AWS 서비스를 어디까지 사용해야 하나?

• 프로젝트 초기 비용적인 문제와 더불어 범용성을 위해 오픈소스를 최대한 활용해보고자 하였는데 생각보다 AWS의 고도화된 자동화 때문에 오픈소스간의 호환이 제대로 되지않아 초기에 생각했던것 보다 더많은 AWS 서비스를 사용하게 되었다. AWS에 대해 제대로 알지 못하여 발생한 문제로 다양한 퍼블릭 클라우드 서비스에 대해 공부를 해야함을 깨달았다.

3-3. 항상 예산과 시간이 문제

• 경험의 부재로 발생한 문제로 해보지 않았으니 어떻게 될지 모른다. 아무리 좋은 가설을 세우더라도 항상 변수는 발생하며 이에대해 어떻게 대응하는지가 중요한듯하다. 많은 경험을 해보자..

4. 마무리

처음으로 퍼블릭 클라우드를 사용하여 진행해본 프로젝트인 만큼 시행착오도 많고 계획한대로 흘러가지 않았던점이 많았다. 계획대로 되지않아도 그 상황에 맞춰 최선의 선택을 했어야 하는데 그 부분이 미숙했던거같다. 하지만 우여곡절이 많아서 오히려 많은걸 배울 수 있던것 같다.

일단 가장 급한건 CKA가 아닐까싶다.

할인 + 달러 인하로 일단 사두었는데 성격상 해야할 일(?)을 쌓아두고 지내지못해서 이 녀석을 가장 먼저 해치울거같다.

그리고 뻔뻔하지만 20대 마지막 여유를 즐길수 있는 시기가 지금뿐일거라는 생각에 CKA를 취득하면 마지막으로 여행을 한번 더 다녀올려고한다.

여행을 갔다오고나서는 아마도 AWS SAA를 준비할거같다. 사실 AWS 자격증에 대해서 큰 관심과 메리트를 못느꼈는데 요새 사람들을 만나보니 따는게 좋을거같다는 생각이 들어서 할려고한다.

물론 코딩테스트나 클라우드 컴퓨팅 (리눅스, 가상화, 도커, 쿠버 등..)에 대한 공부는 평소에도 꾸준히 하고있었지만 위 두개 자격증 취득을 하고나서는 본격적으로 주제와 목표를 정해 프로젝트 방식으로 진행하고 그 내용을 정리하여 포트폴리오겸 정보 공유용으로 블로그에 작성할거같다.

개인적으로는 Hardway구성 등 가상화에 대한 공부를 할거같고 그룹으로는 Istio, Proxy 등 이제껏 했던 내용보다는 조금더 어려운 내용에대해서 공부할듯하다

사실 위 내용말고도 개인적으로 하고있는일이 있지만 병행하는데 있어 크게 부담되진 않아서 여기에 따로 적진않았다.

뭐... 어쨋든 열심히 하셔야겠지..? 😁

카카오 클라우드 스쿨 3기 과정을 거의 마무리하던 시기에 "수료하고나서 뭐하지?" 라는 생각이 들때 SDC Korea 2023가 개최된다는 소식을 들었고 DevOps 및 클라우드 컴퓨팅에 관하여 더 공부를 하고 싶었기에 신청하게되었습니다. 사실은 수료하면 하루종일 침대에서 안일어날거 같아서 일단 신청했다.

📌참석 전

SDC 2023 Events 중에 "삼성전자 S/W 개발 Career 컨설팅"이 있어서 신청하였고 그에 따른 멘토링(?), 컨설팅 준비를 하였다. 예를들어 주니어 개발자로서 어떤 준비를 해야할지, 현업과 기술 트렌드 등...

📌 참석

삼성전자 서초사옥 5층으로 가서 메일로 온 QR 코드를 보여주고 웰컴키트와 소속과 이름이 적혀 있는 명찰을 받았다.

• 웰컴키트의 내용물은 아래 Event에 사진으로 올려두었습니다 !

행사장에는 2개의 Track의 세션을 진행하는 강당이 2개와 각종 전시회, 다양한 이벤트존, 컨설팅 홀, 자그마한 휴게공간 등이 있었다.

📌Expo

기술 세션이 시작하기 전에 엑스포를 방문하여 삼성전자의 전시회 제품을 만날 수 있었고, 여러 기념품도 받을 수 있었다. 하지만 사람도 많고 정신도 없어서 제대로 볼 수 없어 아쉬웠다. 그래도 한눈에 봐도 제품에 대한 이해가 될 수 있게 잘 해두셔서 기억에 남는 제품들이 있었다 !

📌 기술 세션

시간이 되어서 참석하게 된 목적인 기술 세션을 들으러 갔다. 꼭 듣고 싶었던 세션이 있어서 재빨리 가서 입장했다.

간략하게 들었던 내용을 정리해봤습니다. 📚

1️⃣ DevOps Acceleration : 엔터프라이즈에서 동작하는 DevOps 모델

진행 : LG UPLUS의 송주영 연구위원님

요새 대세(?)인 DevOps가 과연 무엇인가? 라는 방황을 하고 있었는데 어느정도 감을 잡을 수 있었던 시간이었던거 같다. 😋

이 세션을 보고 느낀 DevOps에 대해 한 문장으로 요약하자면 아래와 같다.

No Rules, Transparency 그 어떤 경계도 R&R도 없다 S/W의 힘으로 모든 일을 올바르게 가속화 하는 것

그외에도 글로벌 리더 기업의 조직의 운영 및 관리에 대해 배울 수 있었으며 여러모로 큰 자극이 되는 세션이었다 ! 👍

2️⃣ 언제나 Samsung Account는 소리없이 움직인다 : 대규모 트래픽속에서 무중단 클라우드 인프라 업그레이드 아키텍처 소개 및 경험기

진행 : 삼성전자 김제민 파트리더님

Samsung Account 아키텍쳐 소개를 해주시는데 반가운 EKS가 보인다... 개인적으로도 카카오 클라우드 스쿨을하면서도 지겹게 사용하고 괴롭혔던 녀석을 삼성에서도 쓰다니😵‍💫 여튼 아키텍쳐에 대해 설명을 해주시는데 자주 접한 AWS 서비스와 생소한 서비스들도 많았다. 단순히 기술을 사용하는것보다 왜 사용해야하는지가 중요하다고 하셨고 사소한 결정 차이가 비용, 서비스 품질에 대해서는 큰 영향을 끼치신다고 했다! 그리고 관리형 쿠버네티스인 EKS를 무중단으로 업그레이드하는 방식에 대해 자세히 설명을 해주었고 어떠한 점을 고려해야하는지 실제로 어떤 이슈가 생겼는지 다양한 경험을 공유해주셨다. 대규모 트래픽을 다루는 클러스터를 운영해보는 경험은 쉽게 하지 못하기에 정말 값진 경험을 들을 수 있는 기회였다 !

3️⃣ Agile에 안정성을 담기 위한 CI/CD 전략

진행: 삼성전자 황연성 프로님

구글의 DevOps Research and Assessment 팀이 만든 DevOps 성과 측정 지표인 Dora Metrics에 대해 집중적으로 설명해주셨고 상당히 많이 강조하신게 기억에 남는다.

촉박한 개발기간, 잦은 요구사항 추가로 인한 짧은 release cycle을 소화하기 위해 적용했던 테스트 및 CI/CD 전략과 아키텍쳐, 운영방법 또한 배울 수 있었으며 접하기 힘든 현업에서의 CI/CD 전략과 아키텍쳐 등을 이해하고 배울 수 있는 좋은 기회였다.

그리고 또 테라폼을 도입한 이유에 대해 발표를 해주셨는데 이미 구성된 인프라 환경에 import 시켜주는 과정이 너무 힘든작업이었고 하면서도 왜 이걸 하는지 잘 모르겠다고 하셨는데 너무 격하게 공감이 되었다..😇

이렇게 목표로 했던 3가지 세션 모두 다 다행히도 전부 참석할 수 있었고 정말 좋은 경험을 할 수 있었다.

그리고 오후에 SSAFY 교육생 분들의 오픈소스 관련 세션도 있었는데 이 세션도 평소에 접할 수 없었던 DeepLearning 및 AI, MLOps 등에 대해 조금이라도 배울 수 있어서 좋았다 특히 YOLO Object Detection을 활용한 프로젝트가 상당히 기억에 남았다 ⭐️

📌 Events

1. 사전등록 참여자 웰컴키트 증정 이벤트

꼬질꼬질해진 웰컴키트😢

2. 삼성전자 S/W 개발 Career 컨설팅

가벼운 마음으로 신청하였지만 확실히 앞으로 뭘해야 할지 알 수 있었던기회

간단하게 진행한 컨설팅 내용에 대해 작성해봅니다.

Q. 클라우드 엔지니어로서 추천하시는 직무 분야와 공부 해야할 기술 트렌드 등이 있으시다면?

A. DevOps를 계속해라 ! 그리고 현재 트렌드는 AIops, MLops 인듯하다.

---

Q.아래 주제로 클라우드 및 가상화관련 공부를 진행하려고 하는데 어떻게 생각하시나요?? [ Docker없이 컨테이너 만들기, Hardway로 K8S 구성해보기, Istio 등]

A.트렌디하고 좋다! 하지만, 코딩테스트가 최우선이 되어야한다.

---

Q. CS부분은 어떻게 해야할지?

A. 실제로 트러블 슈팅하면서 공부해라! 그리고 아키텍쳐를 구성하면서 왜 이런 내용이 들어가야할지 고찰해봐라.

---

Q. 포트폴리오를 만들면 좋을까요? 예를들어 블로그나.. A. 무조건 해라! 안한거를 후회하고 있다

---

Q. 온프레미스 경력이 클라우드, 가상화 직무에서 인정을 받는지..?

A. 당연히 된다. 경력도 넣고 신입도 넣어라, 어차피 면접관들도 온프레미스 하다 오신분들이다.

3. 지누스마스 비밀 연구원을 찾아라 이벤트

지누와 스마스입니다.

4. 발표자와 함께하는 네트워킹 타임 Talk with Speakers

참석하고싶었지만, 커리어 컨설팅 일정과 겹쳐서 참석할 수 없었습니다.. ㅠ

5. 클로징 세션 LUCKY DRAW 이벤트

갤럭시 플립, 워치, 버즈 등을 추첨을 통해서 준다 ! 결과는 당연히 됐겠냐고 ㅋㅋ

6. SDC23 Korea 만족도 조사 참여 이벤트

전반적으로 만족스러웠고 역시 삼성전자라는 명성에 걸맞게 많은 인파가 찾아왔다. 하지만 장소는 그정도의 인원을 수용할 정도로 쾌적하지 않은...

🏁 마무리

한줄요약 : 롱런을 목표로 열심히 살자

전체 과정을 짧게 되돌아보면서, 그간 어땠는지 한번 되돌아봐도 좋을 것같아 이렇게 작성해봅니다.🥺✨

📕 지원 3기 합격 후기 자세히 보기

광 전송망 운영 업무를 하면서 클라우드로의 전환을 생각하면서 큰 고민과 걱정을 안고 있었습니다.

개발을 하기싫어서 네트워크 엔지니어를 하게되었지만 클라우드전환을 하게되면 다시 개발을 해야하는 과정속에서 걱정을 하고있었고

그 와중에, 개인적인 사정으로 인하여 퇴사를 하게되었고 마침 그 시기에 카카오 클라우드 스쿨 모집을 하였고, 그렇게 지원하게 되었습니다.

교육과정

실제로는 아래에 나와있는 커리큘럼대로 100% 진행이되진않았고 강사님의 재량에 따라 조금씩 변동되었습니다.

🏁 1달 차

기초적인 네트워크 인프라 운용 지식과 이론에 대한 강의가 진행되었고 전공(?)으로 하던 일이었기 때문에 큰 어려움 없이 따라갈수 있었습니다. 하지만 생소한 리눅스, 가상화 영역으로 들어가면서 많이 부족한것을 느꼇고 그때부터 정규 강의시간 외에도 남아서 추가로 공부를 했었습니다. 만약 과정 중 혹은 과정이 끝나자마자 취업생각이 있으신분들은 코딩테스트를 과정 시작과 동시 혹은 그전부터 준비하시는게 좋을것 같습니다.

📚 2달 차

이쯤부터 슬슬 진짜 클라우드 컴퓨팅에 관련하여 배운다고 생각이 들었던거 같습니다. 각종 가상화 기술, VM 등에 대해 다루기 시작하였고 이때부터 재미를 느끼고 개인적으로 프로젝트도 진행해보고 싶다라는 생각이 들었습니다. 어렵고, 생소하였지만 새로운 개념을 알아가는것도 재밌었고 동기분들하고 서로 질문하고 스터디하면서 많은 발전을 할 수 있었던 시간이었습니다.

🔥 3달 차

이제야 말로만 듣던 도커, 쿠버네티스를 다루기 시작했습니다. 처음엔 당연하게도 Docker, K8S Config에 대해 숙지하는게 힘들었지만 토이프로젝트를 진행하면서 자주 접하게 되면서 빠르게 숙지를 할 수 있게 되었습니다.

• 프로젝트간 트러블슈팅을 하면서 느낀점이 있는데 안될때 구글링을 하는것도 좋지만 공식문서를 참고해서 해결하는것이 이슈관리 측면에서도 좋고 공부도 잘되었던거 같습니다. 🧐

또한 중간 중간에 RestAPI와 Python, IaC 등을 배웠지만 도커와 쿠버네티스에 집중하느라 제대로된 기억이 나진 않습니다..

🌧️ 최종프로젝트 (4~6달 차)

🔍 IaC를 통한 AWS인프라 프로비저닝과 CI/CD 파이프라인 구축 (2023.09 ~ 2023.11)

최종 프로젝트이기에, 많은시간과 열정을 들여 완성도있는 프로젝트를 만들고싶었고 아키텍쳐 구성, PoC, 자료조사, 구현 등 지하철에서 버스에서 집에가서 새벽까지도 열심히 했었다. 그런데 어느때쯤 문득 혼자만 너무 프로젝트에 모든 시간을 쏟고있고 남긴게 없다는 생각이 들었고 프로젝트 방향성도 처음에 생각했던것과는 많이 달라져 있었기에 욕심도 많이 사라지고 그 생각이 든 이후로는 개인적인 공부를 많이한거 같습니다. 아래에서도 이야기 하겠지만 프로젝트를 진행하면서 팀원들과 대화를 많이하고 방향성을 잘 잡아가길 바랍니다..

📖 수료

2023년, 클라우드 컴퓨팅 분야로의 첫 걸음을 함께했던 카카오 클라우드 스쿨을 수료하게 되었습니다. 너무 해보고싶었던 과정이었던 만큼 대부분의 과정에 진심으로 참여했고, 정말 많이 성장할 수 있었습니다.

물론 입과하는 개인마다는 목표가 모두 다를 수 있을 것이라고 생각합니다. 하지만, 저의 목표는 6개월동안 최대한 집중해서 많이 배워가는 것 이었고 어느정도 잘 이뤘다고 생각합니다.

물론 항상 좋은 결과만 있는 건 아니었지만 리프레쉬도 되었고 오랜만에 대학교를 다시 다니는 느낌이었습니다 ㅎ..

✅ 카카오 클라우드 스쿨 Tip

입과의 목표를 명확히 둘 것

: 다양한 목표를 갖고 들어옵니다. 하지만 중요한 것 모호하게 했다가는 스스로도 힘들고 함께하는 사람도 힘든 인원을 많이 본거 같아요. 단순히 취업, 프로젝트로 정하라는 것이 아닙니다. 올인이면 올인인 것이 좋지만, 명확하게 몇시까지 프로젝트/수업을 하고 몇시부터는 취업준비를 하겠다는 등의 기준 말이죠.

함께 할 수 있는 과정이고, 또 충분히 취업퇴소하는 인원이 많은 만큼 둘 중 하나로 집중할 필요는 없습니다.

본인이 세운 기준은 유연함은 있지만, 선택에 후회없도록 임하면 이 카카오 클라우드 스쿨 과정이 얼마나 좋은 과정인지 이해할 수 있을 것입니다.

같은 목표를 가진 사람을 찾을 것

: 입과하면 같은 동기들과만 지내게 됩니다. 그렇기에 주변 환경 역시 굉장히 중요합니다. 그렇기에 의지할 수 있고 같이 공부할 수 있는 인원을 만들면 너무 좋습니다. 저는 의가사로 퇴소한 '그' 친구가 가장 기억에 남았네요 ㅎ;

실제 입과하자마자 만나서 수료한 후에도 좋은 연이 되고, 옆에 있으면 자극을 받고 배울 점이 많은 사람입니다.

많은 인원이 아니더라도 단 한두명이라도 얻어가는 것이 정말 중요하다고 느꼈습니다. 짧게는 팀을 구할 때 사용하시고, 길게는 오랫동안 마음을 나누고 의지할 동료를 찾는 것도 좋습니다.

카카오 클라우드 스쿨의 환경을 최대한 활용할 것

: 현직의 개발 활동을 많이 해보신 강사/멘토님과 앞기수를 해본 선배 기수분들, '일' 하다 오신 동기분들 등 환경을 최대한 활용해보는게 중요하다고 생각합니다.

물론, 개개인이 다 만족스러운 환경을 얻진 못할 수도 있습니다. 하지만 개인으로 누릴 수는 없는 환경임은 확실합니다. 그렇기에 필요한 것이 있다면 적극적으로 요청하고 부족하거나 궁금한게 있다면 물어보는 것이 중요합니다.

카카오 클라우드 스쿨이 학교가 아니라는 것을 기억할 것

: 마음가짐으로는 너무 중요하고 너무 기본인 것 같지만, 다시 한 번 중요하다고 생각했습니다.

카카오 클라우드 스쿨에서 교육을 받지만, 저는 이 과정을 사회생활로 생각했습니다. 실제로 현장에서 어디서든 만날 사람이라고 생각했기 때문이죠. 알바나 인턴하는 것처럼 언행과 행동에 조심하려고 했습니다만 ...

🌈 마무리

클라우드 분야를 배우고 싶다는 생각에 큰 결심으로 카카오 클라우드 스쿨에 입과했고 수료하게 되었네요. 오랜만에 많은사람들하고 수업을듣고 프로젝트를 진행해보니 상당히 좋은 리프레쉬가 된듯합니다.

저는 23년 수료를 하고, 한동안은 자택경비원으로 지내다가 내년부터 다시 취업준비를 하지 않을까 싶네요. 제가 겪었던 어려움과 부족한 점을 조금이라도 해결하고, 본인 인생에 임팩트나 전환점이 되거나 스스로에게 자신감이 생길 수 있는 교육생이 단 한명이라도 있다면 좋겠다는 바랍입니다.

카카오 클라우드 스쿨을 지원하거나, 지금 하고 계신 분, 또 동기/선후배 분들까지 모두 고생많으셨습니다 !

열심히 하셨잖아, 한잔해

Elasticsearch + Fluentd + Kibana

• Fluentd: 로그 수집

• Elasticsearch: 수집된 로그를 검색 및 분석하여 저장

• Kibana: ES를 통해 데이터 시각화

구성환경

• VMware Ubuntu20.04 이미지 활용

• Manager Node에서 ElasticSearch, Kibana를 Docker Container로 실행

• Fluentd를 Daemonset으로 K8S 클러스터에 배포하여 log를 수집

사전조건

• 도커와 쿠버네티스가 설치되어 있어야한다.
• 편의를 위해 방화벽을 끄고 진행한다.
• Dockerhub를 이용하여 이미지를 만들고 저장할 것이므로 docker login을 미리 해준다.
• ElasticSearch 컨테이너 Exited를 방지하기위해 vm.max_map_count를 262144로 변경 해주어야 한다.

진행과정

1. ElasticSearch, Kibana Docker로 Manager Node에 Container로 실행
2. Nginx Pod를 Deployment로 배포
3. Fluentd를 Daemonsets로 배포
4. Kibana로 정상적으로 동작하는지 확인
5. 보완사항

1. ElasticSearch, Kibana Docker로 띄우기

1-1. ElasticSearch

구성간에 편의를 위해 http 통신이 되게끔 진행하였습니다.

Docker 작업전 아래 와 같이 입력하여 vm.max_map_count를 변경합니다. [ Ref ] - vm.max_map_count

sudo sysctl -w vm.max_map_count=262144

ES Dockerfile 작성

# 베이스 이미지로부터 시작합니다.
FROM docker.elastic.co/elasticsearch/elasticsearch:7.10.1

# Root 권한으로 전환하여 패키지를 설치합니다.
USER root

# Elasticsearch 컨테이너에서 Vim을 설치하는 명령어를 실행합니다.
RUN bin/elasticsearch-plugin install analysis-phonetic

# Docker 이미지 내에서 실행될 명령어를 지정합니다.
CMD ["/usr/share/elasticsearch/bin/elasticsearch"]

ElasticSearch Docker build & Run

docker build -t my_elasticsearch .
docker run -d -p 9200:9200 -e "discovery.type=single-node" -e "http.host=0.0.0.0" my_elasticsearch

우선 설정 파일을 확인하기위해 컨테이너 내부로 진입하자

여기서 확인해야 할 파일은 ~/config/elasticsearch.yml 입니다.

sudo docker exec -it 엘라스틱서치 컨테이너명 /bin/bash

elasticsearch@c00a7b999cf1:~$ cat config/elasticsearch.yml
cluster.name: "docker-cluster"
network.host: 0.0.0.0

#----------------------- BEGIN SECURITY AUTO CONFIGURATION -----------------------
#The following settings, TLS certificates, and keys have been automatically
#generated to configure Elasticsearch security features on 30-10-2023 17:49:37
#--------------------------------------------------------------------------------

###Enable security features
xpack.security.enabled: true

xpack.security.enrollment.enabled: true

###Enable encryption for HTTP API client connections, such as Kibana, Logstash, and Agents
xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/http.p12

###Enable encryption and mutual authentication between cluster nodes
xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12
#----------------------- END SECURITY AUTO CONFIGURATION -------------------------

여기서 변경해야 할 값은 xpack.security.enabled 값으로 true에서 false로 변경해주면 됩니다.

[ Ref ]. ElasticSearch Security-Settings

ES 보안 기능을 활성화하는 값으로 false로 비활성화하자.

이는 보안에 대해 사용하지 않는 설정이므로 주의하여 사용할 필요가 있습니다.

1-2. Kibana

Kibana Docker run

• Masternode(BastionHost)의 IP를 아래에 넣어서 실행시켜줘야합니다.

docker run -d -p 5601:5601 -e "ELASTICSEARCH_HOSTS=http://BastionHost IP:9200" docker.elastic.co/kibana/kibana:7.10.1

1-3. Container 상태 확인

elasticsearch

kibana

2. Nginx 배포하기

먼저 Access.log를 Fluentd가 읽을수 있는 Json 형식으로 바꾼 nginx 이미지를 만들어 주어야합니다.

Dockerfile

# Use an official Nginx image as the base image
FROM nginx:latest

# Copy the custom Nginx configuration that enables JSON format logs
COPY nginx.conf /etc/nginx/nginx.conf

nginx.conf

이 부분에서 access_log를 사용자 설정으로 바꿧는데 그 이유에 대해서는 맨 아래에서 설명하겠습니다.

events {
    worker_connections 1024;
}

http {
    log_format json_logs escape=json
        '{"time_local": "$time_iso8601", '
        '"remote_addr": "$remote_addr", '
        '"request_method": "$request_method", '
        '"request_uri": "$request_uri", '
        '"status": $status, '
        '"body_bytes_sent": $body_bytes_sent, '
        '"http_referer": "$http_referer", '
        '"http_user_agent": "$http_user_agent"}';

    access_log /var/log/nginx/mulrung.log json_logs;

    server {
        listen 80;
        server_name localhost;

        location / {
            root /usr/share/nginx/html;
            index index.html;
        }
    }

Build 및 Push

#본인의 Dockerhub repo와 이미진 네임 태그를 지정해서 빌드를한뒤 push를하자
docker build -t  dockerhubID/name:Tag .
docker push dockerhubID/name:Tag 

nginx.yaml

• Mount를 시킨이유는 fluentd와 nginx간 Host의 디렉토리에서 log를 읽고 쓰게 하기 위함이다.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: nginx-deployment
  spec:
  replicas: 3  # 원하는 파드 수로 설정
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: dockerhubID/name:Tag
        ports:
        - containerPort: 80
        volumeMounts:
        - name: varlog
          mountPath: /var/log/nginx
      volumes:
      - name: varlog
        hostPath:
          type: DirectoryOrCreate
          path: /var/log/
  

#### 배포해보자

kubectl apply -f nginx.yaml

#### 실제로 nginx가 띄워진 Node에 mount가 되었는지 확인해보자

root@worker1:~/Dockerfile# ls /var/log/ | grep mulrung mulrung.log

 ---

# 3. fluentd Daemonset으로 배포하기
#### fluentd daemonset 으로 설치하기 위해 메니페스트 파일을 다운받는다. 

curl -LJ -o fluentd.yaml https://github.com/fluent/fluentd-kubernetes-daemonset/blob/master/fluentd-daemonset-elasticsearch-rbac.yaml?raw=true

다운받은 fluentd.yaml에서 FLUENT_ELASTICSEARCH_HOST의 value 값을 ElasticSearch를 띄운 호스트의 ip로 변경하면 됩니다.

      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch
        env:
          - name:  FLUENT_ELASTICSEARCH_HOST
            value: "[elasticsearch 호스트 ip]"
          - name:  FLUENT_ELASTICSEARCH_PORT
            value: "9200"
          - name: FLUENT_ELASTICSEARCH_SCHEME
            value: "http"

그리고, 이 포스팅에서는 nginx의 Log를 확인할것이므로 수정한 fleunt.conf가 들어간 이미지를 새로 만든다.
-   path /var/log/mulrung.log -> nginx를 배포할때 보면 알수 있듯이 nginx의 access 로그를 사용자 설정으로 만든것이다.
- host의 IP부분은 수정해야한다.


#### fluent.conf

# 다운 받은 메니패스트의 기본 이미지명
FROM fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch

# 수정한 conf 파일 Copy
COPY fluent.conf /fluentd/etc/fluent.conf

#본인의 Dockerhub repo와 이미진 네임 태그를 지정해서 빌드를한뒤 push를하자
docker build -t  dockerhubID/name:Tag .
docker push dockerhubID/name:Tag 

그 이후 fleuntd.yaml의 이미지를 Hub에 푸쉬한 이미지로 변경한다.

containers:
      - name: fluentd
        image: dockerhubID/name:Tag

배포해보자

kubectl apply -f fluentd.yaml

4. 확인

• pod및 Contaienr가 정상적으로 Running중 임을 확인할 수 있다.

• kibana의 Stack Management > Index Management nginx*로 해서 데이터가 쌓이는 것을 확인할 수 있다. Create Index pattern을 통해 인덱스 패턴을 만들어주자.

• Kibana의 Index Pattern에서 nginx*로 설정한 후 discover에서 확인해보자.

• curl을 통해 nginx에 접속을하게되면 log가 쌓이는것을 볼 수 있다.

5. 사연

사실 이 포스팅은 원래 EKS 환경에서 진행하려고했었다. 하지만 EKS에서는 위와같은 방법으로는 되지않았고 그 원인을 찾다가 지쳐서 로컬환경에서 진행한 내용으로 포스팅하게 되었습니다..

해결해야할 문제들

1. 쿠버네티스(?) 혹은 EKS 환경에서 nginx의 기본 access 로그인 access.log가 접근이 안된다. 그래서 파일을 새로만들었습니다.

-> stdout 설정으로 인하여 contaienrs의 로그에 심볼릭링크가 걸려있는듯하다.(?) 2. EKS에서는 동일하게 진행하여도 왜 안되는지 모르겠다. -> gid, uid 기타 설정 생각나는건 다해봤는데 안된다..

다양한 형태의 컨테이너 런타임과 오케스트레이터 사이의 네트워크 계층을 구현하는 방식이 다양하게 분리되어 각자만의 방식으로 발전하게 되는 것을 방지하고

공통된 인터페이스를 제공하기 만들어 졌고, 쿠버네티스에서는 Pod 간의 통신을 위해서 CNI 를 사용한다.

쿠버네티스 뿐만 아니라 Amazon ECS, Cloud Foundry 등 컨테이너 런타임을 포함하고 있는 다양한 플랫폼들은 CNI를 사용하고 있으며,

쿠버네티스는 기본적으로 'kubenet' 이라는 자체적인 CNI 플러그인을 제공하지만 네트워크 기능이 매우 제한적인 단점이 있다.

그 단점을 보완하기 위해, 3rd-party 플러그인을 사용하는데 그 종류에는 Flannel, Calico, Weavenet, NSX 등 다양한 종류의 3rd-party CNI 플러그인들이 존재한다.

CNI의 필요성

예를들어, 위 그림과 같이 컨테이너 기반으로 동작하는 애플리케이션에 Web UI 컨테이너, Login 컨테이너, 장바구니 Cart 컨테이너 이렇게 멀티 호스트로 구성하였을때

Web UI, Login, Cart 컨테이너는 서로 간에 당연히 통신이 되어야 한다.

UI 컨테이너(172.17.0.2) 에서 Login 컨테이너(172.17.0.2) 로 통신을 하기 위해 트래픽을 보낸다고 가정했을때

정상적인 통신 패턴이라면 UI 컨테이너는 veth0 인터페이스를 통해 docker0 라는 브릿지 인터페이스를 타고 NAT처리 되어 worker node #1의 물리 인터페이스인 ens160의 IP(10.200.155.22) 로 나간다.

그 후,  worker node #2 의 물리 인터페이스인 ens160 (10.200.155.23) 으로 들어와 docker0 브릿지 인터페이스를 통해 Login 컨테이너의 veth0으로 들어온다.

그러나 위 그림에서 보듯이, 두 컨테이너의 IP는 동일하기 때문에 UI 컨테이너에서 Login 컨테이너로 통신을 시도하면 자기 자신인 UI 컨테이너 로컬로 통신을 시도 할 것이고

위와 같은 멀티 호스트로 구성되어 있는 컨테이너 끼리 통신을 하기 위해서는 CNI가 반드시 설치되어 있어야한다.

CNI는 Calico, Weavenet, AWS CNI 등 매우 다양한 종류가 있다.

위 그림에서는 weave net이라고 하는 CNI가 브릿지 인터페이스를 만들고 컨테이너 네트워크 대역대를 나눠주며

라우팅 테이블까지 생성하여 UI 컨테이너가 Login, Cart 컨테이너로 통신하는데 전혀 문제 없도록 지원한다.

CNI에서 사용되는 네트워크 모델

CNI Provider는 VXLAN(Virtual Extensible Lan), IP-in-IP 과 같은 캡슐화된 네트워크 모델 또는 BGP (Border Gateway Protocol)와 같은 캡슐화 되지 않은 네트워크 모델을 사용하여 네트워크 패브릭을 구현한다.

CNI 3rd-Party 플러그인 종류 및 지원하는 기능

@ Dockerfile 작성

# 사용할 베이스 이미지를 선택
FROM ubuntu:latest

# 이미지 내에서 명령어 실행
RUN apt-get update
RUN apt-get install -y python3

# 컨테이너가 시작될 때 실행할 명령어
CMD ["python3", "-c", "print('Hello, Docker!')"]

@ v1.0 태그로 Build 진행

docker build -t my-simulation-image:v1.0 .

@ 이미지가 정상적으로 Build 되었는지 확인

@ 이미지 실행 결과 Hello, Docker!가 정상적으로 출력된다.

@Dockerfile의 Print 구문을 수정해보자

# 사용할 베이스 이미지를 선택
FROM ubuntu:latest

# 이미지 내에서 명령어 실행
RUN apt-get update
RUN apt-get install -y python3

# 컨테이너가 시작될 때 실행할 명령어
CMD ["python3", "-c", "print('Hello, yourface')"]

@ 동일하게 v1.0 태그로 Build를 해보자

docker build -t my-simulation-image:v1.0 .

@ 동일 태그의 이미지를 실행해보면 변경사항이 적용된걸 확인할 수 있다

#2. Dockerfile의 내용변경없이 참조하는 쉘스크립트의 내용 변경하여 테스트

@ Dockerfile 작성

# 사용할 베이스 이미지를 선택
FROM ubuntu:latest

# 이미지 내에서 명령어 실행
RUN apt-get update
RUN apt-get install -y bash

# 스크립트 파일 복사
COPY my_script.sh /usr/local/bin/

# 스크립트 실행 권한 부여
RUN chmod +x /usr/local/bin/my_script.sh

# 컨테이너가 시작될 때 실행할 명령어 (스크립트 실행)
CMD ["/usr/local/bin/my_script.sh"]

@ Shell 스크립트 작성

#!/bin/bash

echo "This is a simple Shell script executed in a Docker container."
echo "Hello, Docker!"

@ v1.0 태그로 Build 진행

docker build -t my-script-container:v1.0 .

@ 이미지 실행 결과, 정상적으로 Shell 스크립트의 내용이 보인다

@ Shell 스크립트의 내용을 수정한 후 동일 태그로 빌드해보자

#!/bin/bash

echo "This is a simple Shell script executed in a Docker container."
echo "Hello, mulrung!"

---
docker build -t my-script-container:v1.0 .

@ 이미지 실행 결과, 변경사항이 잘 적용된다.

카카오 클라우드 스쿨 수료 후 두번째로 취득한 자격증입니다. 쿠버네티스에 대해 조금더 알아보고 사용해보고 싶어 약 1달간의 공부끝에 CKA 자격증을 취득하였습니다.

📖 공부 방법

모두들 활용하는 유데미의 뭄샤드님의 강의를 활용하여 준비하였으며 시험 응시시 접속할 수 있는 killer.sh은 단순히 환경을 체험하는 용도로만 사용하였습니다.

특별한 공부방법은 없으며 강의에 있는 모든 카테고리를 Kubedocs를 참고하여 풀 수 있을정도로만하면 별 문제없이 합격할 수 있다고 생각듭니다.

🎯 빈출 유형

1. Create PersistentVolumeClaim & Patch Capacity
2. Node Troubleshooting
3. Cluster update Only Master (except etcd, cni, manager)
4. Etcd Backup & Restore
5. Ingress
6. NetworkPolicy
7. Deployment Scale Up
8. Create MultiContainer
9. RBAC (ServiceAccount, Clusterrole, ClusterroleBinding)
10. Sidecar
11. Node Drain
12. Extract Error Logs
13. Write Pod name using the most CPU
14. Number of Ready Nodes without taitns
15. Node Selector
16. Service (Container port name)
17. Create pv, pvc, pod

💡 시험 Tip

CKA 시험의 만료일은 구입 기간으로부터 1년 뒤이므로, 만료되기 전까지 자신이 가능한 시간대로 선택하여 고르면 됩니다. 시험 날짜는 응시 하루 전까지 자유롭게 변경할 수 있습니다. 또한, 불합격하더라도 1번의 재시험을 볼 수 있는 기회를 제공해줍니다.

시험 시간은 총 2시간이 주어지며, 주어진 시간보다 빠르게 시험을 마쳤다면 중도에 종료할 수 있습니다. 참고로, 본인 확인을 위한 신분증을 사전에 지참해야 합니다. 감독관이 외국인이므로, 주민등록증보다는 여권을 준비하는 것을 권장합니다.

시험 전에 반드시 Check System Requirements 메뉴에서 자신이 시험을 응시하는 환경이 적절하게 세팅되었는지 확인해야 합니다.

저는 Mac (Chrome)환경에서 시스템 체크를 하였습니다. -> 현재 23.12기준 Safari를 이용하여 체크하면 OS버전 체크가 정상적으로 안됩니다.

다음은 시험 당일에 반드시 숙지하고 있어야 할 사항들입니다.

저는 편의를 위해 스터디카페 그룹룸을 빌려 응시를 하였으며 시험시간 앞뒤로 30분 여유를두어 예약을 하였습니다.

시험 시작 30분전부터 Test Exam 메뉴가 활성화되며 PSI브라우저를 설치한 후 여권 등의 신분증명을 한다음 감독관이 웹캠을 통해 주변 환경에 대한 점검을 진행합니다.

그리고나면 시험이 진행되는데 PSI브라우저 안에서만 시험을 응시할 수 있으므로 killer.sh을 통해 충분히 환경에대해 적응을 할 필요가 있습니다.

또한 각 문제마다 kubectl config user-context 명령을 통해 매번 특정 컨텍스트로 전환해야 하므로, 컨텍스트 전환이 제대로 이뤄졌는지 꼭 확인해야 합니다.

문제 하단의 flag 기능을 통해 잘 풀리지 않거나 오래 걸릴 것으로 예상되는 문제들은 체크해놓을 수 있습니다.

🌈 마무리

1달동안 준비하였지만 순 공부시간은 100시간도 안되었던거 같습니다. 난이도는 저 같은 사람도 시험을 본후 "별일없으면 100점이겠다" 라고 생각할 정도니 편한마음으로 공부하시고 응시하시면 될거같습니다.

지원 계기

클라우드 전환을 생각하여 기존에 하던 광 전송망 운영 업무를 그만두고 카카오 클라우드 스쿨에 지원하게 되었습니다. -> 카카오 클라우드 스쿨만 보고 퇴사를 결심한건 아니고 그 외에 복합적인 환경을 생각했습니다.

서류

퇴사 후 귀국하는 비행기에서 간단하게 작성했던걸로 기억이 납니다. 어렴풋이 기억나는 내용들은 자격증, 외국어 능력 등 보통의 지원서와 같았고 적당하게 적당한 내용으로 작성하면 별 문제 없이 통과될듯합니다.

필기

온라인으로 진행을하였는데 인터넷 검색이 가능해서 큰 어려움은 없었습니다. 면접에서 물어볼수도 있으니 나온 문제를 기억해두고 모르는것은 공부해두면 도움이 될듯합니다.

면접

편안한 분위기에서 진행되며, 자소서에 적은 프로젝트 및 경험을 기반으로 질문을 하십니다. 그 외에 CS, 네트워크, 백엔드, 프론트엔드에 관한 질문을 받을 수도 있으니 간단하게 공부해가면 좋을듯합니다. ex) OS, Rest API, 3 Tier Architecture, Protocol etc..

본인이 클라우드 컴퓨팅, 가상화에 대해 공부하였다면 해당 내용에 대한 질문을 유도하면 더 좋을듯 합니다.

Q&A

궁금한 사항이 있으면 댓글 부탁드립니다.

수료 하게되면 과정 후기도 남기겠습니다.

감사합니다.

애플리케이션은 그것이 실행되는 호스트가 반드시 충족해야 하는 종속성이 있으며 컨테이너 시대 이전의 개발자들은

이러한 작업을 부가적인 방법으로 수행했다. ex) 자바 애플리케이션은 데이터베이스와 통신하기위해 방화벽 규칙이 함께 실행되는 JVM이 필요하다.

결론적으로 도커는 컨테이너를 실행하는 방법 중 하나이다.

아래에서 도커, 컨테이너, 이미지에 대해 알아보자

Docker란?

Docker는 애플리케이션 구축, 구현 및 테스트를 위해 격리된 가상화 환경을 생성하는 서비스형 플랫폼이다.

Docker는 컨테이너 엔진으로 리눅스 커널 기능을 사용하여 운영 체제 위에 컨테이너를 만들고,

Docker 자체는 서비스의 컨테이너를 관리하는 데몬으로 실행된다.

• Linux 커널의 도커 엔진

• Ref. https://ragin.medium.com/docker-what-it-is-how-images-are-structured-docker-vs-vm-and-some-tips-part-1-d9686303590f

Docker image란?

도커에서는 애플리케이션을 포장 및 전송하기 위해 "docker image"를 사용한다.

Docker image는 파일로 어플리케이션 실행에 필요한 독립적인 환경을 포함하며, 런타임 환경을 위한 일종의 템플릿이다.

도커 이미지는 소스 코드, 라이브러리, 종속성, 도구 및 응용 프로그램을 실행하는데 필요한 기타 파일을 포함하는 불변(변경 불가) 파일이다.

이미지는 읽기 전용이므로 스냅샷이라고도 하며, 특정 시점의 애플리케이션과 가상 환경을 나타낸다.

이러한 일관성은 도커의 큰 특징 중 하나로 개발자가 안정적이고 균일한 조건에서 소프트웨어를 테스트하고 실험할 수 있도록 한다.

이미지는 템플릿일 뿐이므로 시작하거나 실행할 수 없다. 컨테이너는 실행 중인 이미지일 뿐이기 때문이다.

컨테이너를 생성하면 쓰기 가능한 레이어가 immutable image(불변 이미지) 위에 추가된다. 즉, 컨테이너는 수정이 가능하다.

컨테이너를 생성하는 이미지 베이스는 별도로 존재하며 변경할 수 없다.

컨테이너 환경을 실행할 때는 기본적으로 컨테이너 내부에 해당 파일 시스템(도커 이미지)의 읽기-쓰기 복사본을 만든다.

이렇게 하면 이미지 전체 복사본을 수정할 수 있는 컨테이너 레이어가 추가된다.

• Ref. https://phoenixnap.com/kb/docker-image-vs-container

하나의 베이스 이미지에서 도커 이미지를 무제한으로 생성할 수 있다.

이미지의 초기 상태를 변경하고 기존 상태를 저장할 때마다 추가 레이어가 있는 새 템플릿을 만든다.

따라서 도커 이미지는 여러 개의 레이어로 구성될 수 있으며, 각각은 다르지만 이전 레이어에서 비롯된다.

이미지 계층은 컨테이너 계층을 사용하여 가상 환경을 시작할 때 추가된 읽기 전용 파일을 나타낸다.

• Ref. https://ragin.medium.com/docker-what-it-is-how-images-are-structured-docker-vs-vm-and-some-tips-part-1-d9686303590f

• Docker image creation

docker build -t=myimage .

Docker container란?

사용자가 기본 시스템에서 애플리케이션을 분리할 수 있는 가상화된 런타임 환경이다.

이러한 컨테이너는 응용프로그램을 빠르고 쉽게 시작할 수 있는 portable units 이다.

중요 기능은 컨테이너 내부에서 실행되는 컴퓨팅 환경의 표준화다. (standardization of the computing environment running inside the container.)

응용 프로그램이 동일한 환경에서 작동하도록 할 뿐 아니라 다른 사람과의 공유도 단순화한다.

컨테이너는 자율적(autonomous)이기 때문에 strong isolation을 제공하며 서로 방해하지 않는 격리된 환경을 제공한다.

하드웨어 수준에서 가상화가 이루어지는 VM과 달리 컨테이너는 애플리케이션 계층에서 가상화된다.

하나의 머신을 활용하고 커널을 공유하며 분리된 프로세스를 실행하기 위한 운영 체제를 가상화할 수 있다.

따라서 컨테이너가 매우 가벼워져 리소스를 많이 사용하지 않을 수 있다.

• Ref. https://phoenixnap.com/kb/docker-image-vs-container

• Docker container creation

docker run -d --name mycontainer -p 8080:8080 myimage

도커 이미지와 컨테이너의 차이점은 무엇인가? Docker Images vs Container

둘은 밀접한 관련이 있으며 도커 플랫폼에 의해 정의된 시스템의 일부이다.

컨테이너가 존재하려면 이미지를 실행해야 하는 반면, 이미지는 컨테이너 없이 존재할 수 있다.

따라서 컨테이너는 이미지에 종속되어 런타임 환경을 구성하고 애플리케이션을 실행하는 데 사용된다.

도커 이미지는 도커 컨테이너에서 코드를 실행한다. 실행 중인 컨테이너를 만들려면 도커 이미지에 핵심 기능의 쓰기 가능 계층을 추가한다.(Writable container)

도커 컨테이너는 실행 중인 이미지 인스턴스로 간주한다. 각각의 고유한 데이터와 상태를 가진 동일한 이미지에서 여러 개의 컨테이너를 만들 수 있다. 컨테이너 채택의 주요 이점은 개발, 운영 및 테스트의 표준화 및 단순화이다.

CI/CD 파이프라인은 컨테이너를 빌드, 테스트 및 패키징할 수 있다. 그런 다음 배포는 해당 컨테이너를 애플리케이션의 일부로 실행할 수 있는 런타임 환경에 배포한다.

Dockerfile, Image, Container?

Dockerfile --(Build)--> Image --(Create)--> Container

Dockerfile은 도커 이미지를 빌드하는 방법을 정의하는 스크립트이다.

Docker에서는 환경 정보를 저장하는 파일을 Dockerfile이라고 한다. 이 Dockerfile에는 컨테이너의 구동에 필요한 정보가 작성되어 있다.

Docker file을 빌드해서 이미지를 생성한다.

이미지는 특정 환경에 대한 정보가 변하지 않고 저장되는 정적인 형태의 파일이다.

이미지를 동적인 형태로 변경한 것이 컨테이너이며, 컨테이너가 구동된다는 것은 우리가 필요로 하는 OS와 특정 환경이 경량 가상화로 구현된다는 것을 의미한다. 컨테이너는 어플리케이션을 실행할 격리된 환경이다.

다시 말하면 컨테이너를 생성하는 것은 다른 환경과 분리시킨 환경을 만든다는 말이고, 컨테이너를 구동하는 것은 분리된 프로세스화하여 특정 환경을 만드는 것이다.