♥DGB I'm challenger 2주차 교육♥

클라우드 컴퓨팅 (Cloud Computing)

- Digital Transformation의 핵심적인 기술(factor) 중 하나

# 4차산업혁명시대의 발발

  18C 후반부터 1차산업혁명이 시작되었다. 대량생산을 가능하게 한 증기기관을 기반으로 공장들이 많이 생겨났다. 그 후 전기가 등장하면서 19C 말 2차 산업혁명이 도래되었다. 컨베이어벨트를 통한 대량생산이 가능해졌고, 1969년 최초의 인터넷, ARPA가 처음 만들어지면서 3차 산업혁명 시대로 도달했다. 컴퓨터는 이전에도 나왔지만, 컴퓨터 간의 네트워크가 가능해짐에 따라 3차 산업혁명, 정보화 시대라고 일컫는다. 마침내 4차 산업혁명은 다보스포럼(2012)의 주제로써 독일에서 처음 등장하게 되었다.

 

  인공지능, 빅데이터, 초연결 사회인 4차 산업혁명시대는 기존의 지능정보기술과 산업 및 서비스, 기술을 융합한다. 4차 산업혁명의 주요 키워드는 ICBM(IOT, CloudComputing, Big Data, Machine Learning(AI))이다. 

 여기서 CloundComputing은 가장 중요한 개념이라고 할 수 있는데, 그 이유는 센서 장치를 이용하여 데이터(BigData)를 수집하면, 그것을 저장하고 분석(Machine Learning)하는데에 필수적이기 때문이다.

 

  Cloud의 본질적 의미는 구름인데 인터넷을 처음 그릴 때, 구름으로 그렸기 때문에 이름을 Cloud Computing가 되었다.

2011년을 기점으로 클라우드 컴퓨팅이라는 단어의 관심도가 줄어들었는데, NIST 미국 국립표준연구원에서 

 

NITS에서 정의한 클라우드 컴퓨팅이 되기 위한 조건(특성)

 

1. On-Demand self-service

 누군가가 해주는 것이 아니라 내가 원하는 서비스를 설치해서 사용

2. Broad network access

 광대역 네트워크를 통해서 가상 서버를 활용 

3. Resorce pooling

 가상서버는 이미 다 만들어져 있다. 만들어놓은 가상서버를 사용하기만 하면 됨

4. Rapid elasticity

 탄력적임. 가상 서버가 부족하면 그것을 바로바로 충족시켜줄 수 있어야 함

 몇개월, 몇개월 후를 예측하기 어렵기 때문에 자동적으로 할 수 있는 서비스를 구축하자는 것에서 유래

 가상서버가 파일이기 때문에 단순히 복사해주기만하면 늘어남

5. Measured service

  분당 혹은 시간당 서버 사용량에 따라 비용을 지불할 수 있게끔 정확하게 측정해야함

 

# 클라우드컴퓨터의 종류

 

 전기나 수도를 정부에서 제공하는 것을 빌려주는 것을 사용하듯이, 서버를 빌릴 수는 없을까 ?

서버에서 제공하는 IT 자원을 필요한 만큼 빌려서 사용한 만큼 비용을 지불하는 컴퓨팅 패러다임을 클라우드 컴퓨팅이라고 말한다.

 

 서버에 올려서 사용하는 것들

- ON PREMISES = 모두 다 빌리는것

 

Iass

- INFRASTRUCTURE = 상위 5개를 빌림, 인프라만 !

pass

- PLATFORM = 서버 프로그램(python, java)까지 빌림 -> 개발자들이 주로 빌림

saas

- SOFTWATE =  아예 데이터, 소프트웨어 등 모든 것을 다 빌리는 것(icloud) 

 

CSP( Cloud Service Provider )란 ?

=> 클라우드의 서비스를 제공하는 업체

=> 휴대폰을 구입할 때, LG, SK, KT를 선택해서 사용하는 듯이 클라우드를 이용할 때에도 클라우드 서비스를 제공하는 업체를 선택해야 함

=> 대표적으로 아마존 AWS, 마이크로소프트 Azure, 구글클라우드 플랫폼 (GCP) 등이 있

 

MSP( Managed Service Provider )란 ?

=> 클라우드 인프라 관리 서비스를 제공하는 업체=> 즉, CSP와 고객을 연결하는 역할로 클라우드 구축과 전환, 운영을 설계하고 운영해주는 서비스를 제공함.=> MSP의 역할은 마이그레이션( 기존 인프라에서 클라우드로 이동하는 것 ), 컨설팅, 운영 관리 등이 존재함

 

Virtualization

 서버를 관리한다는 것은 생각보다 복잡하고 많은 것을 자동적으로 수행할 줄 알아야 한다. 서버의 플랫폼과 개발환경은 자주 변화되어서 유동성이 많이 요구되어진다. 여기서 가상화(Virtualization)가 많은 도움을 준다. 데이터 센터 안의 서버 위 메모리(Server Racks)에 우리가 만든 가상환경(Virtualization)이 올려진다. 메모리를 뜯지 않는 이상 확인해볼 수 없다. 그렇기에 볼 수 없어서 구름위에 떠있다는 그림으로 형상화되었다고 할 수 있다.

 

Virtualization이란,  물리적인 하드웨어 장치를 논리적인 객체로 추상화(=가상화)하는 기술

 

 즉, 가상화를 통해 machine을 그릴 수 있다.

왼쪽 그림은 가상화가 이루어지지 않은 경우, 오른쪽 그림은 가상화가 이루어진 경우를 그림으로 나타낸 것이다.

오른쪽 그림의 상단에 VM0, VM1 ----- 은 각각의 가상환경을 의미한다.

가상환경은 OS를 여러개 사용할 수 있는 것은 장점이지만, 각각의 메모리, cpu 등등을 개별적으로 돌려야하기 때문에 무겁고 느리다.

 

 가상환경이 등장하게 된 배경은, 자원의 절약이다. 과거에는 비싼 CPU를 피크타임을 위해 구매하여 오랜시간 돌리지만, CPU의 성능은 고작 6 ~ 12% 밖에 실행되지 않는다. 이는 컴퓨터의 효율이 떨어지기 때문에 하나의 컴퓨터의 CPU의 성능을 많이 사용해주기 위해서 가상환경을 설치해 CPU 성능을 분배해주는 것이다.

 따라서, 물리적인 하드웨어인 CPU를 조금 더 효율적으로 사용하기 위한 목적으로 등장했다. 

 

# Type 1 Virtualization ( Hypervisor Virtualization = Bare Metal)

-> 밑에서부터 하드웨어, OS, 가상환경들이다. 초기의 가상화 시스템은 너무 무겁다는 단점이 있다. hostOS도 존재하지 않는다. Hypervisor가 HostOS 역할을 해준다.

 

# Type2 Virtualization (Host Virtualization)

2세대 가상화

 

-> HostOS가 존재한다. 단계가 늘어났기 때문에 설치하는 것을 쉽지만, 제일 무겁고 느린 방식에 해당한다.

 

 

# Type3 Virtualization (Container Virtualization)

 

 " HostOS도 리눅스 서버이고, GuestOS도 리눅스 서버이면, 굳이 GuestOS가 필요할까 ? "

똑같은 일을 2번 하지 말자는 전제로 Container Virtualization이 등장하게 되었다.

 CPU 뿐만 아니라 를 쪼개서 각각의 가상환경에 나누어서 하드웨어를 격리화시킨다.만약, 가상환경의 데이터에 보안문제가 생겼을 때, 하드웨어에는 영향을 끼치지 않도록 한다는 강력한 장점이 존재한다.

 

이전 방식과 달리 Guset OS를 두지 않고, Host OS의 커널(이것만 사용)을 그대로 사용하면서 Linux Container(리눅스 컨테이너)를 사용하여 HostOS와 다른 부분만 패키징하고 Host의 리소스를 공유하여 기존 가상머신 보다 리소스를 효율적으로 사용할 수 있는 가상화환경GuestOS가 사라졌기 때문에 가장 가볍고 빠르다는 장점을 가지고 있다.

 

단, 하드웨어와 OS를 하나로만 사용하지만, 리눅스 컨테이너 기술을 사용하기 때문에 반드시 리눅스 서버를 사용해야 한다.리눅스 컨테이너 기술은 HostOS 위에 Docker Engine을 사용해야한다.

 

Container

* 컨테이너라고 불리는 이유 ?

=> 배에 올리는 컨테이너는 서로의 Size를 표준화해서 동일하기 때문에, 전 세계 어디에서 사용하더라도 동일하게 해석할 수 있고 서로서로 패키지화하고 격리되어져 있기 때문에 영향을 끼치지 않는다.

 

따라서, 컨테이너는 환경과 상관없이 실행을 위해 모든 요소를 포함하는 소프트웨어 패키지의 일종이라고 생각할 수 있다.

 

만약에 MySQL과 Word Process 둘 다 제공하고 싶으면 컨테이너 하나에 같이 넣는게 아니라 각각 따로 컨테이너를 만들어주고, 두 개의 컨테이너가 상호작용을 할 수 있도록 연결하는 네트워크를 생성해야 한다.

 

* LXC (Linux Container)

 

컨테이너 vs 컨테이너 이미지

 

 컨테이너는 어플리케이션을 실행하기 위한 환경을 제고아는 격리된 실행단위이고,컨테이너 이미지는 컨테이너를 생성하는데 사용되는 템플릿이나 청바지를 의미한다. 

컨테이너는 컨테이너 이미지를 기반으로 생성되며, 여러 개의 컨테이너가 동일한 이미지를 공유할 수 있다.

 

Docker는 Layered File System 기반으로 컨테이너 이미지는 적층형으로 쌓아올라간다. 하나의 컨테이너 이미지가 하나의 layer로 층층이 쌓아져 있기 때문에 필요하면 층을 쌓고 빼고를 자유롭게 할 수 있다.

 Rigister에 있는 이미지는 read only이고, Docker_Container에 올라온 이미지는 수정할 수 있다.

 

Base Image는  원래 우분투에 있었던 이미지이고, 메모리에 올리기 위해서는 run 명령어를 실행시켜준다.

그럼 Container에 원하는 어플리케이션이 층으로 쌓이고, commit 해주면 자신만의 컨테이너 이미지인 Custom Image가 된다.

Base Image

 

$ docker run -it --name git ubuntu:latest bash => 컨테이너 안으로 들어가는 명령어

'

- apt update

필요한 패키지를 설치하기 전에 항상 update 시켜주기

- root@9fb2faf09844:/# apt-get install -y git

git 설치- $ docker commit git ubuntu:git git을 commit하고 이름은 ubunut:git(태그)으로 지정해주겠다는 의미

git commit 후

 

Docker Host에 pull 해야 수정이 가능함

 

• 초기화 시키는 방법

docker ps -a

docker image ls = docker images

docker system prune -a

docker volume prune

• Volume Mount

만약, 컨테이너에 이미지를 올

 

-v 내 위치번호 : container 위치번호

ubuntu@ip-172-31-1-185:~$ mkdir mydb
# 파일 생성
ubuntu@ip-172-31-1-185:~$ ls
mydb
ubuntu@ip-172-31-1-185:~$ cd mydb
# 현재 위치 확인
ubuntu@ip-172-31-1-185:~/mydb$ pwd
/home/ubuntu/mydb
# -d
# -p : 포트포워딩
# -v : 볼륨 마운팅
# -e : 
ubuntu@ip-172-31-1-185:~$ docker run -d -p 3306:3306 -v $HOME/mydb: /var/lib/mysql -e MYSQL_ROOT_PASSWORD=password mysql:latest
# 결과 값 : 77735b51df48c1e56f8877c477c76b0957cf29f0f9339f9d715b68b299d13828

ubuntu@ip-172-31-1-185:~$ docker container ps -a
CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS    PORTS     NAMES
77735b51df48   mysql:latest   "docker-entrypoint.s…"   40 seconds ago   Created             db
ubuntu@ip-172-31-1-185:~$ ls
mydb
ubuntu@ip-172-31-1-185:~$ cd mydb
ubuntu@ip-172-31-1-185:~/mydb$ pwd
/home/ubuntu/mydb
ubuntu@ip-172-31-1-185:~/mydb$ ls
'#ib_16384_0.dblwr'   auto.cnf        ca-key.pem        ib_buffer_pool   mysql.ibd            public_key.pem    undo_001
'#ib_16384_1.dblwr'   binlog.000001   ca.pem            ibdata1          mysql.sock           server-cert.pem   undo_002
'#innodb_redo'        binlog.000002   client-cert.pem   ibtmp1           performance_schema   server-key.pem
'#innodb_temp'        binlog.index    client-key.pem    mysql            private_key.pem      sys
ubuntu@ip-172-31-1-185:~/mydb$ 

ubuntu@ip-172-31-1-185:~$ docker exec -it db bash
bash-4.4# mysql -u root -p
mysql> show databases;

 

• PortPowording

내 위치번호 : container 위치번호

 

• Container Volume

Memory에 있는 데이터는 휘발성이기 때문에 영구적으로 보관하기 어렵다. 따라서 메모리에 있는 데이터를 하드디스크에 저장해야 영구적으로 사용할 수 있다.

 

Volume 옵션 사용

1.  -v {Host path} : {Container Mount path}

=> 

2. -v {Host path} : {Container Mount path} : {Read Write Mode} - ro, rw(기본) 

=>

3. -v {Container mount path}

=>좌우가 똑같은 경로로 데이터를 저장하기 때문에 한쪽을 생략

 

Container 데이터 공유하는 법

 Storage에 있는 개념을 컨테이너가 공유할 수 있다. 이는 같은 storage를 사용하기 때문에 각 컨테이너에서 발생하는 정보를 같이 저장할 수 있는데, 이 때 data transaction이 발생한다. 

ex) 통장에서 동시에 입금하고, 출금할 때 어떤게 더 먼저 일어날까 ? => 데이터 충돌

이러한 문제점은 하나 컨테이너는 rw, 나머지 컨테이너는 ro라고 옵션을 주어서 데이터를 읽고, 쓰는 역할을 나누어주면 해결된다.

만약, 여러개의 컨테이너가 있으면, 옵션은 2가지 밖에 없기 때문에 어쩔수 없이 data transaction이 발생하는데 이것을 해결해주는 기능이 쿠버네티스이다. 

 

Docker

Docker 회사가 2013년에 일반인들도 컨테이너를 사용할 수 있도록 표준화해주는 Docker 기술을 발표함.

Golang이라는 언어로 생성했고, OS가 생략된 기술이고, 일반적으로 Docker라고 하면 Docker Engine을 가리킨다.

Docker가 등장하면서 개발 패러다임이 변화되었다. 도커는 이미지라는 단위로 컨테이너를 생성하는데, 이러한 이미지들은 도커 허브(Docker Hub)와 같은 저장소에 저장되어 다른 사람과 공유할 수 있다.

+) 여기서 이미지라는 단위란, png, jpg 같은 파일이 아니라, 이미지 파일 중에서도 iso라는 이미지 단위를 의미한다.

 

도커의 구조

• Docker Client(Docker) = 도커를 실행시키는 명령어 전달
• Docker Registry = 도커의 이미지 저장소
• Docker Host = 실행되어지는 실질적인 장소

Docker Client(명령)에서 이미지를 다운로드 받으면 Docker Registry에 있는 이미지가 다운받아지면서 메모리에 Images에 올라가고, 이 하나의 이미지는 하나의 프로세스로 Containers로 이동되어진다. 이 Docker daemon이 있는 곳을 Docker Host라고 한다.

Docker Host의 실행은 리눅스 서버 OS가 실행하고, Docker 실행이 중점적으로 이루어진다.

 

• Docker Compose

격리되어진 Container 끼리 Docker Network를 묶어버리면 서로 연결되어진다.

 

• Docker Swarm

많아진 Container들을 관리하는 역할을 수행함

 

Docker를 사용하는 이유

• Application의 개발과 배포가 편해짐

=> 개발자들이 앱을 만들면, 시스템 엔지니어가 회사 서버에 올리는 순간 작동되지 않는다. 그 이유는 만들어진 환경이 다르기 때문이다.  하지만, 이를 이미지로 생성하면 사양이 똑같아지기 때문(표준화)에 문제가 발생하지 않는다.

• 서버관리가 쉬어짐

=> 사이즈가 똑같기 때문에 어디서나 무엇이든 만들어진 이미지가 도커위에 올라간다. 따라서 서버관리가 더욱 쉬워진다.

=> 서버 관리를 잘한다는 것은 정보를 문서화하고, 다양한 툴을 잘 활용할 수 있어야 하며, 가상화 머신을 만들고(하지만 무거움), 어렵고 복잡한 기능을 사용하기 쉽게 해야 한다.

 

Docker Network

 

컨테이너끼리 네트워크를 할 수 있도록 하는 목적을 가지고 있으며, libnetwork project라고 불린다.

+) 자신의 네트워크를 보여줌

=> eth0은 각 컨테이너(리눅스 환경)의 (실제)랜카드를 의미하고, docker0는 Gateway, 빨간색 eth0은 바깥으로 통과할 수 있는 브릿지 역할을하는 랜카드에 해당한다. 각 컨테이너는 서로서로 통신할 수 없기 때문에 veth라는 가상 랜카드를 설정해주어서 두 컨테이너를 연결해준다. 

 

ex) MYSQL(데이터베이스) & WEB(웹서버)라는 두 컨테이너를 연결해줄 때의 구도화

 

 먼저 web 컨테이너를 보았을 때, eth0(setOS의 랜카드)은 실제 랜카드, docker0(브릿지)는 docker를 설치했을 때 생기는 가상의 랜카드(state DOWN/state UP), 컨테이너를 하나 생성하면 veth가 생성되는데, 이것또한 가상 랜카드이고, docker0와 연결하는 역할을 한다. 결과적으로 이렇게 연결시켜주면, 하나의 컨테이너가 사용할 수 있는 IP는 2개가 된다.

 근데, db 같은 경우에는 docker0이 아니라, my_bridge라는 가상 랜카드가 발생한다. 그럴경우 두개의 랜카드가 통신을 할 수 없기 때문에 아래와 같이 추가적인 랜카드(브릿지)를 발생시켜 해결할 수 있다.

어떤 브릿지를 사용하냐에 따라 IP 대역대가 달라진다. 같은 IP 대역대여야지만, 네트워크가 가능하다는 것을 알 수 있다.

 

 

docker0 = 컨테이너와 네트워크를 연결할 수 있는 가상의 랜카드

 

state DOWN으로 보이면, 컨테이너가 하나도 존재하지 않음을 의미

컨테이너가 하나라도 존재하면, state UP이 표시됨

 

veth0에 해당하는 랜카드 =  veth2f01162@if63

 

 

Docker Compose

 Container를 만들기 위해서 도커파일을 만들어야하는데, 도커파일 하나는 곧 Container 하나에 해당한다. 도커파일 하나로 컨테이너 하나를 만들 수 있는데, 도커파일 하나로 두개의 컨테이너를 동시에 만들고 싶을 때 Docker Compose 개념을 활용한다.

 여기서 Config라는 개념이 추가되는데, run 할 때 쓰는 옵션이 여러개 포함된 것이 config이다. 그리고 container에 올릴 이미지와 옵션에 해당하는 config를 묶어 yml(야물)파일로 만들어주는 것이 Docker Compose이다.

 도커 컴포즈 안에는 이미지가 여러개 있을 수 있지만, 하나의 셋트로 묶어준다. docker-compose 파일을 up/down 명령어만을 통해서 컨테이너에 올릴 수 있다. (이미지를 올릴 때 옵션 설정 안해도 됨)

 

docker-compose.yml 파일의 예시 / 올리기 => web과 redis라는 컨테이너를 동시에 만들 수 있음

 

 

Docker Compose를 사용하는 이유

• Docker 실행 명령어를 일일이 입력하기 복잡함

ex) 다른 부서에서 우리부서가 만든 컨테이너를 사용할려면 명령어를 일일이 다 알려주어야 함

• Container 간의 연결이 불편함 => 환경변수 -e를 일일이 설정해주어야 함
• 특정 Container끼리만 통신할 수 있는 가상 네트워크 환경을 편리하게 관리하기 위해서

앞서 설명한 datatransaction이 발생할 우려가 있기 때문에 전용선을 만들어주어 특정 컨테이너끼리만 통신할 수 있게 하는 방법으로 해결할 수 있지만, 이것또한 일일이 명령어을 적용해야하기 때문에 복잡함

• 이 모든 것을 간단한 명령어로 관리하고 싶어서

 

쿠버네티스 (Kubernetes)

 

 쿠버네티스란, "오픈소스 컨테이너 오케스트레이션 플랫폼"이다. 

쉽게 말해서 컨테이너화된 애플리케이션의 관리를 자동화할 수 있도록 도와주는 플랫폼이며, 데브옵스, MSA(Microservies), 컨테이너, CI/CD(지속적인 통합/배포)와 밀접한 관계를 가진다.

 굳이 따지자면, 개발쪽 보다는 서버를 운영하는 쪽에 더 가깝다고 할 수 있다.

 

 가장 큰 장점으로 꼽히는 것은 OS와 관계없이 다양한 클라우드 환경에서 이용할 수 있어 어플리케이션의 확장성을 높여준다.

또한, 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 어플리케이션을 여러 개의 노드에 분산시켜 실행하므로, 하나의 노드나 컨테이너에 장애가 발생해도 다른 노드나 컨테이너에서 어플리케이션을 계속 실행할 수 있다.

 

 

---

AWS 실습

 

 

 

 

Docker 실습

- Docker는 모든 명령어가 Docker로 시작

 

 

 

HeidiSQL

https://www.heidisql.com/

HeidiSQL - MariaDB, MySQL, MSSQL, PostgreSQL and SQLite made easy

 

HeidiSQL을 설치한 뒤, AWS 고유 IP주소와 암호, SQL과 연결되어 있는 보안포트 숫자를 입력한다.

그 후 데이터베이스 선택지에서 원하는 것을 선택해준 뒤 열기를 누르면 아래와 같이 자신이 원하는 데이터베이스로  이동한다.

 

 

Web Server 만들어보기

 

Docker.hub 사이트에서 웹 서버에 해당하는 httpd 기능을 찾는다.

 

가장 최신의 버전에 들어가면 히스토리가 나와 있는 깃허브로 이동하게 되는데, 

expose 80이 이 기능의 포트번호이고, 경로를 알 수 있다.

 

Docker.hub에 자신의 repository를 생성한다.

 

# httpd 최신버전 다운받기
ubuntu@ip-172-31-1-185:~$ docker pull httpd:latest

# 여러가지 설정주고 httpd 불러오기
ubuntu@ip-172-31-1-185:~$ docker run -d -p 80:80 --name web httpd

# 실행되고 있는지 확인
ubuntu@ip-172-31-1-185:~$ curl localhost:80

# container 안으로 들어감
ubuntu@ip-172-31-1-185:~$ docker container exec -it web bash

# it works가 실행되고 있는 홈페이지의 경로를 찾아서 출력
root@ffb7341b9ca6:/usr/local/apache2# cd /usr/local/apache2/htdocs
root@ffb7341b9ca6:/usr/local/apache2/htdocs# ls
index.html

# echo 명령어로 it works를 Docker TestPage로 변환한다.
root@ffb7341b9ca6:/usr/local/apache2/htdocs#  echo "<html><body><h1>Docker TestPage</h1></body></html>
" > index.html

 

IP를 url에서 확인하면 실행되고 있음을 확인

 

 

Repository로 Commit 하는 법

# web을 myweb으로 변환
ubuntu@ip-172-31-1-185:~$ docker commit web myweb

# web 컨테이너 삭제
ubuntu@ip-172-31-1-185:~$ docker container rm -f web

# docker hub로 로그인 -> 아이디 비번 입력
ubuntu@ip-172-31-1-185:~$ docker login

# myweb이라는 이미지를 docker hub 경로와 tag 시켜줌
ubuntu@ip-172-31-1-185:~$ docker tag myweb jeonsuhyeon00/practice:latest
# docker hub에 push
ubuntu@ip-172-31-1-185:~$ docker push jeonsuhyeon00/practice:latest

# 이미지가 없을 시 해결방법
ubuntu@ip-172-31-1-185:~$ docker run -d -p 80:80 --name webserver httpd
ubuntu@ip-172-31-1-185:~$ curl localhost:80
# 이렇게 하면 webserver에서 실행되는 문구 출력

# webserver를 myweb이라는 이름으로 image commit
ubuntu@ip-172-31-1-185:~$ docker commit webserver myweb

# 이미지 디렉토리 확인
ubuntu@ip-172-31-1-185:~$ docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED         SIZE
myweb        latest    a768cfaf9396   7 seconds ago   167MB
mysql        latest    73246731c4b0   4 weeks ago     619MB
httpd        latest    92fa43a2ff60   2 months ago    167MB

# myweb이라는 파일을 내 리포지토리 경로와 연결시켜 tag해줌
ubuntu@ip-172-31-1-185:~$ docker tag myweb jeonsuhyeon00/practice:latest

# docker push 명령어로 내 리포지토리에 파일을 올려줌
ubuntu@ip-172-31-1-185:~$ docker push jeonsuhyeon00/practice:latest

 

 

Docker Compose 실습

 

vi inde.html 안에 들어가는 코드

<font size=‘7’ color=‘red’>Hello Docker Compose</font>

 

 

다른 셸에서 실행시켰을 때,  아래 그림과 같이 실행시킨 셸에서 접근한 정보가 업데이트 된다.

 

 

도커파일 생성

 

이미지 생성

 

도커 실행시켜보기

 

 

docker-compose.yml 생성하기

 

 

 

 

 

 

다 지우고 docker-compose up -d 실행시켜주었을 때 결과 값

 

 

+) IaC (Infrastructure as Code) 공부하기,,

 

Container 2개를 docker-compose up 시켜주기

-> docker-compose.yml 파일 만들어주기

 

-> 성공 !