9년 전인 2013년 3월, Solomon Hykes와 그의 공동 설립자들은 Docker라는 오픈 소스 플랫폼으로 소프트웨어 개발 방식을 혁신했습니다. Docker의 제작자는 컨테이너를 발명하지 않았지만 대중화했습니다. Docker 덕분에 개발자들은 GitHub Codespaces와 같은 도구를 생성하여 클라우드에서 호스팅되는 개발 컨테이너에서 코딩할 수 있습니다.
개발 컨테이너에 대해 처음 들었을 때 두 가지 질문이 있었습니다.
- 사람들이 컨테이너 내부에서 개발하는 이유는 무엇일까?
- 컨테이너란 무엇인가?
비슷한 의문이 있는 경우 이 글을 읽어주세요.
이 블로그 게시물에서는 컨테이너가 무엇인지, 개발자에게 어떤 이점이 있는지, GitHub Codespaces에서 devcontainer를 설정하는 방법을 설명하겠습니다.
컨테이너 내부에서 개발한다는 것의 의미
혹시 "제 PC에서는 잘 동작해요" 라는 말을 해본 적이 있으신가요? (아마 많은 분들이 경험이 있으실 겁니다.)
이 말을 해본 적이 없으실 수도 있겠지만, 실제로 개발자가 환경이 다양한 코드베이스에서 작업하는 경우 자주 말하게 되는 문구입니다. 다양한 환경에서 작업하는 것이 이상적이지는 않지만 실무에서는 발생할 수 밖에 없습니다. 제 경험상 이런 상황은 내 로컬 환경, 동료의 로컬 환경, 스테이징 및 프로덕션이 모두 약간의 차이가 있을 때 발생합니다. 환경 구성이 약간 다르기 때문에 한 환경에는 버그가 존재했지만 다른 환경에는 존재하지 않을 수 있습니다. 로컬에서는 작동하지만 프로덕션이나 스테이징에서는 작동하지 않는 기능을 빌드하거나 버그를 수정하는 것은 매우 창피하고 좌절감을 느낄 수 있는 일입니다.
그러나 컨테이너는 일관성 없는 개발자 환경의 문제를 해결합니다. 컨테이너를 사용하면 소프트웨어 엔지니어가 일관된 환경에서 프로그래밍할 수 있습니다. 이제 코딩 환경은 동일한 운영 체제, 구성 및 종속성을 사용하여 프로덕션을 미러링할 수 있습니다. 이렇게 하면 모든 환경에서 버그와 기능이 동일하게 작동하여 개발자가 "내 컴퓨터에서 작동합니다." 라고 말하는 부끄러움을 덜 수 있습니다.
이제 컨테이너의 목적을 이해했으므로 Codespaces에서 컨테이너를 활용하는 방법을 살펴보겠습니다.
GitHub Codespaces는 소프트웨어 및 클라우드 개발을 한 단계 끌어 올립니다.
GitHub Codespaces를 사용하면 클라우드에서 호스팅되는 컨테이너에서 코딩할 수 있습니다. 이러한 맥락에서 클라우드는 컴퓨터가 아닌 인터넷에 있는 환경입니다.
빠른 온보딩
일반적으로 소프트웨어 엔지니어는 팀에 합류할 때 로컬 환경을 설정할 책임이 있습니다. 로컬 환경 설정에는 필수 종속성, 린터, 환경 변수 등의 설치가 포함됩니다. 개발자는 문서의 품질에 따라 환경을 구성하는 데 최대 일주일을 소비할 수 있습니다. 개발자들은 보통 바로 코딩을 하고 싶어하기 때문에, 복잡한 개발 환경 설정 때문에 고통받는 것을 굉장히 싫어합니다.
다행스럽게도 우리는 GitHub Codespaces를 사용하여 온보딩 프로세스를 자동화하여 사용자 지정 환경을 구성할 수 있습니다. 새로운 개발자가 팀에 합류하면 필요한 확장, 종속성 및 환경 변수가 코드 공간 내에 존재하기 때문에 코드 공간을 열고 로컬 환경 설정을 건너뛸 수 있습니다.
어디서나 코딩할 수 있습니다.
Codespaces를 사용하면 인터넷에 액세스할 수 있는 곳이면 어디에서나 코딩할 수 있습니다. 기기를 바꾸거나 집에서 노트북을 잊어버린 경우, 리포지토리를 복제하고, 선호하는 IDE를 다운로드하고, 로컬 환경을 설정하지 않고도 비행기에 있는 동안 iPad에서 작업을 쉽게 진행할 수 있습니다. 이것은 Codespaces가 브라우저 내에서 Visual Studio Code와 유사한 편집기를 열기 때문에 가능합니다. 가장 좋은 점은 내 변경 사항을 내 저장소에 푸시하는 것을 잊은 경우에도 Codespaces가 내 코드를 자동 저장할 수 있다는 것입니다.
일관된 환경
위의 단락에서 언급했듯이 컨테이너를 사용하면 미러링된 프로덕션 환경에서 작업할 수 있습니다. GitHub Codespaces는 컨테이너를 사용하기 때문에 프로덕션 환경에서와 동일한 결과와 개발자 경험을 로컬 환경에서 얻을 수 있습니다.
또한 인프라 변경과 같이 코드베이스에 변경 사항이 발생하면 로컬 환경이 중단될 수 있습니다. 로컬 환경이 중단되면 개발자 환경을 복원하는 것은 개발자의 몫입니다. 그러나 GitHub Codespaces의 컨테이너 사용은 개발자 환경에 균일성을 제공하고 손상된 환경에서 작업할 가능성을 줄입니다.
Codespace를 구성하는 데 필요한 세 개의 파일
devcontainer.json 파일, Dockerfile 및 docker-compose.yml 파일의 세 가지 파일을 활용하여 Codespaces 환경을 팀 동료와 함께 사용할 수 있습니다. 이러한 각 파일은 리포지토리 루트의 .devcontainer 디렉토리에 있습니다.
devcontainer.json 파일
devcontainer.json 파일은 GitHub Codespaces에 코드 공간 구성 방법을 알려주는 구성 파일입니다. devcontainer 파일 내에서 다음을 구성할 수 있습니다.
- 확장
- 환경 변수
- Dockerfile
- Port forwarding
- 생성 후 커맨드
- 등등
즉, 사용자 또는 누군가가 codepspace를 열 때마다 devcontainer.json 파일에 지정하는 확장, 환경 변수 및 기타 구성이 지정된 저장소에서 코드 공간을 열 때 자동으로 설치됩니다. 예를 들어 사람들이 나와 같은 린터와 확장자를 가지기를 원하면 devcontainer.json 파일에 다음을 추가할 수 있습니다.
{
"name": "Node.js",
"build": {
"dockerfile": "Dockerfile",
// 노드 버전(18, 16, 14)을 선택하려면 'VARIANT'를 업데이트하세요.
// OS 버전을 고정하려면 -bullseye 또는 -buster를 추가하세요.
// 로컬 arm64/Apple Silicon인 경우 -bullseye을 사용합니다.
"args": { "VARIANT": "16-bullseye" }
},
// 도구별 속성을 구성합니다.
"customizations": {
// vscode 설정
"vscode": {
// vscode 확장을 설정할 수 있습니다.
"extensions": [
"dbaeumer.vscode-eslint", // this is the exentension id for eslint
"esbenp.prettier-vscode", // this is the extension id for prettier
"ms-vsliveshare.vsliveshare", // this is the extension id for live share
]
}
},
// Port forward 설정
// "forwardPorts": [],
// 컨테이너 생성 시 커맨드 설정
// "postCreateCommand": "yarn install",
// root로 연결하려면 주석처리. 자세한 정보: https://aka.ms/vscode-remote/containers/non-root.
"remoteUser": "node"
}Dockerfile
Dockerfile은 GitHub Codespaces에 컨테이너를 빌드하는 방법을 알려주는 구성 파일입니다. 여기에는 이미지를 생성하는 동안 Docker 클라이언트가 호출하는 명령 목록이 포함되어 있습니다. Dockerfile은 컨테이너의 설치 및 구성을 자동화하는 데 사용됩니다. 예를 들어 컨테이너에 Node.js를 설치하려는 경우 Dockerfile에 다음을 추가할 수 있습니다.
FROM node:16-bullseyeDockerfile 설정에 대한 자세한 설명은 공식 문서를 참고하시면 좋습니다.
docker-compose.yml 파일
Codespace에는 docker-compose.yml 파일이 꼭 필요하지는 않지만 여러 컨테이너를 실행하려는 경우에 사용합니다. 예를 들어 Codespace에서 데이터베이스와 웹 서버를 각각 실행하려는 경우 docker-compose.yml 파일을 사용하여 두 컨테이너를 모두 실행할 수 있습니다. docker-compose.yml 파일에 대한 자세한 설명을 공식 문서를 참고해주세요. 다음은 데이터베이스에 연결하는 docker-compose.yml 파일의 예입니다.
version: '3.8'
services:
app:
build:
context: ..
dockerfile: .devcontainer/Dockerfile
args:
VARIANT: "3"
NODE_VERSION: "none"
volumes:
- ..:/workspace:cached
command: sleep infinity
network_mode: service:db
db:
image: postgres:latest
restart: unless-stopped
volumes:
- postgres-data:/var/lib/postgresql/data
hostname: postgres
environment:
POSTGRES_DB: my_media
POSTGRES_USER: example
POSTGRES_PASSWORD: pass
POSTGRES_HOST_AUTH_METHOD: trust
ports:
- 5432:5432
volumes:
postgres-data: null
코드스페이스는 GitHub의 웹 편집기와 다릅니다.
GitHub Codespaces는 GitHub의 웹 편집기와 다릅니다. 웹 편집기는 "."를 눌렀을 때 나타나는 편집기입니다. 리포지토리에서. 저장소의 파일을 편집할 수 있는 경량 편집기입니다. 웹 편집기는 파일을 약간 변경하는 데 적합하지만 전체 스택 웹 응용 프로그램을 작성하고 실행하는 데는 적합하지 않습니다. GitHub 웹 편집기에는 터미널이 없기 때문입니다. 그러나 Codespaces를 사용하면 터미널 등을 갖춘 브라우저에서 본격적인 IDE를 실행할 수 있습니다.
Github 웹 편집기와 Codespaces 의 차이점은 Github 공식문서에서 자세한 내용을 확인 할 수 있습니다.
읽어주셔서 감사합니다.
