wy_family

Docker CLI API - 우리 입장(개발자)에서는 거의 dockerD와 함께 하는 것인데, dockerD의 업무가 무엇이 있냐면, 우리가 던지는 모든 도커 명령어, 모든 CLI를 다 받아준다. docker command. swarmkit - 지금 수업에서는 단순하게 처음에는 싱글 모드의 도커를 쓸 것이다. 물론 싱글 모드 서버 두 대를 만들 건데, 도커 서버 한 대 만들고 그거를 Virtual Box에서 복제 기능이 있어서 복제 기능을 통해서 두 대의 서버를 가지고 연습을 할 것이다. 그 다음에 이제 docker swarm 에 가면, 세 대의 호스트 OS, 이걸 가지고 docker swarm 을 만들어서 컨테이너 서비스를 멀티 클러스터로 확장을 할 것이다. 그 때 쓰는 기술이 swarm 인데, 그 ..

컨테이너 엔진(특히 Docker Engine)의 작동 방식은 컨테이너 기술의 핵심인 커널 공유 원칙에 기반을 두고 있으며, 컨테이너 생성, 관리, 운영을 체계적으로 처리하기 위해 다양한 컴포넌트가 협력합니다. 아래에서 Docker Engine의 구성요소와 작동 원리를 구체적으로 설명할게요.1. Docker Engine의 구성 요소Docker Engine은 다음 세 가지 주요 컴포넌트로 구성되어 있습니다.(1) dockerD (Docker Daemon)Docker의 핵심 프로세스이자 사용자와 Docker Engine의 나머지 컴포넌트 사이를 연결하는 중앙 관리자.사용자의 명령(Docker CLI나 API 요청)을 받아서 실행에 필요한 작업을 orchestrate(조율)합니다.주요 역할:컨테이너 생성/운영/..

어플리케이션 배포 방식은 일반서버(온프레미스), 가상머신(VM), 컨테이너(Container)로 크게 나뉩니다. 각각의 방식을 하나씩 비교하면서 구체적으로 설명해 볼게요.1. 일반서버(온프레미스)개념실제 물리적인 하드웨어 서버에 어플리케이션을 배포하는 방식.운영체제(OS)가 하드웨어 위에서 직접 동작하며, 해당 OS 위에 어플리케이션이 실행됩니다.특징독립성 부족: 하나의 서버에 여러 어플리케이션을 설치하면 서로 영향을 주기 쉬움. 예: A 앱이 많은 메모리를 사용하면 B 앱의 성능 저하.고비용: 서버를 직접 구매, 설치, 유지보수해야 함.확장성 제약: 추가 서버가 필요할 경우 물리적인 서버를 구매하고 설치해야 하므로 시간이 오래 걸림.운영체제 공유: 하나의 OS가 모든 어플리케이션과 직접 연결되어 있음...

Docker 컨테이너 가상화와 VM 가상화를 비교해보고자 한다. 가상화(Virtualization)란 무엇인가?**가상화(Virtualization)**는 컴퓨터 시스템의 물리적 리소스를 소프트웨어적으로 추상화하여, 여러 논리적 시스템(가상 머신, 네트워크 등)을 하나의 물리적 장치 위에서 실행할 수 있도록 하는 기술입니다. 이는 기업과 개인이 하드웨어를 효율적으로 활용하고, 관리의 편의성을 높이며, IT 운영 비용을 절감할 수 있도록 도와줍니다.가상화의 핵심 개념리소스 추상화가상화는 물리적 리소스(서버, 스토리지, 네트워크 등)를 논리적으로 추상화하여 사용자가 물리적 제약 없이 이를 사용할 수 있게 합니다.예: 하나의 물리 서버를 여러 개의 가상 서버로 분할하거나, 여러 개의 물리 스토리지를 하나의 논..

컨테이너 가상화에 대한 이해를 하기 전에, 나는 Docker 기반으로 CICD 파이프라인 구축하기에 대한 학습을 했었다. 간단한 실습도 해보면서 docker가 무엇인지, 컨테이너가 무엇인지, 가상화는 무엇인지, 어떤 장점이 있었는지 등등에 대한 이해를 했었다. 하지만, 뭐든지 여러번 반복적으로 보지 않으면 암기가 되는건 아니기 때문에, 이해를 확실하게 했었는데 막상 "설명해보세요" 라고 하면 '그럴 듯 하게' 설명할 수는 없다. 그냥 아내가 "설명해줄래요?" 라고 하면 이해 시켜줄 수는 있지만 격식있는 자리에서 설명해야 하는 상황이라면, 진땀뺄 일이다.어쨌든, 쿠버네티스까지 공부를 하기 위해서 도커부터 공부를 다시 시작하려고 한다.나는 백엔드 개발자를 희망하고 있다. 그리고 클라우드 기술을 활용할 줄 아..

디지털 비즈니스는 점점 더 복잡해지고 더 빨라지고 있습니다. 이러한 속도에 적응하기 위해서 인프라가 코드화되면서 코드를 통한 개발과 배포의 통합과 자동화는 CI/CD 라는 이름으로 개발자의 필수 기술 셋이 됐습니다.- 인프라가 코드화가 되었다 --> Cloud- 코드를 통한 개발과 배포 --> Cloud- 통합과 자동화CI/CD! 그래서 Docker, Linux, Cloud, CI/CD Pipeline, GitLab 을 통한 학습을 했다. Docker를 이용해서 애플리케이션을 패키징 할 수 있습니다. 애플리케이션을 위한 라이브러리, 빌드 시스템, 런타임, 코드 뿐만 아니라 운영체제에서 제공하는 PID, USER, Volume, IPC, Network 까지 함께 패키징 할 수 있습니다. 이를 통해서 어디에..

개발자가 feature branch를 만들고 feature branch 에 대한 Merge Request를 하고 승인을 하면파이프라인이 작동해서 새로 배포되는 것까지 확인을 했다.그런데, feature branch 를 push를 하게 될 경우에 GitLab은 새로운 코드의 변경 사항을 확인하고feature branch에 대해서도 파이프라인을 작동시켜버렸다.결과적으로 아직 검증이 끝나지 않은 상태에서 서비스가 업데이트가 되어버린 것이다.이 경우에는 feature branch의 어떤 변화에 대해서는 CI/CD 파이프라인이 작동하지 말아라라는 예외 조건을 줘야 한다.예외조건을 설정하는 것을 보자.--> CI/CD Pipeline를 수정해보면 해결 가능하다. 해당 job 이 main 에서만 실행되도록 조건을 걸..

push를 했더니 에러가 떴다.그러니까 push라는건, 그냥 막 밀어넣겠다는건데,그게 아니라 merge request를 해서 main branch에 변화를 주어야 한다.그럴려면 branch를 생성했었어야 하고, 그 branch에서 코드를 개발해야 한다는 걸 의미한다고 생각한다.그래야 나중에 merge를 요청하지 않을까. MR (Merge Request)우선, branch를 새로 뻗고 기능 개발을 한 뒤에 MR 을 하기 전에,아까 push 하려고 commit 했던 걸 없애버려야 한다.git reset --hard HEAD~1git reset --hard HEAD~1 명령어는 Git에서 이전 커밋 상태로 되돌리고, 현재 작업 중인 파일 변경 사항과 스테이징된 모든 변경 사항까지 모두 삭제하는 강력한 명령어입..

지금까지는 CI/CD 파이프라인 설계하고 구축하는 걸 했지만 '혼자' 작업하는 상황이었다.그런데 현실에서는 함께 일하는 상황일 것. 그러면, Group, project, user, permission 설정이 필요하다.그러니까 Merge Request와 Approve 설정이 있을 것.+Slack을 이용한 CI/CD 모니터링, Slack 연동과 CI/CD 이벤트 메시지 전송을 해볼 것.어찌됐든 지금까지 한 것들은 '혼자' 작업하고 있는 상황이었다보니 간단한 CI/CD 파이프라인을 구축했었다.하지만 실제 협업할 때는 여러 가지 상황들, 여러 조건들이 필요하다. 실제로 서비스 중인 어떤 Main Branch 가 있다고 해보자.개발자가 뭔가를 개발할 때, Main Branch를 가지고 바로 개발/적용을 하면 위험..

GitLab-runner 가 배포를 하게 될 것이다.Gitlab-runner가 배포하는 방식은 gitlab-runner에서 aws 명령어를 실행하게 될 것이다.aws cli, 설치를 안 했으면 하면 된다.aws cli 명령 중에서는 ecs를 컨트롤할 수 있는 명령을 제공한다.ecs의 cluster를 만들거나 service를 새로 실행(running)하거나 하는 등의 작업을 수행할 수 있다.ECR에 새로운 어플리케이션이 올라가있는데, 거기에 코드 내용을 수정하고 새로운 버전의 docker image를 올리고그리고 service를 새로 실행(running)하게 될 것이다.service를 새로 실행하게 되면은 새로 만들어진 docker image를 가지고 와서 service가 올라오게 될 것이다.이 과정을 테..