클라우드 40일차(docker, LXC, docker lifecycle, docker container)

여기 ovs를 나중에 컨트롤러 스위치와 연결할 예정이다. ovs는 그대로 두고

ovs 안에 가보면 eth0이 포함되어 있다.

 

또 내부에 가상 스위치와 머신들도 만들어져있다.

옆에는 스토리지가 있고 각 vm에 마운트 되어 있다.

 

---

 

 

예전에는 가상화를 중소규모에서는 할 수 없었음.

 

도커를 구성한다면 위와같이 서버 4대를 구성하고 서버 클러스터를 구현할 것이다. 그리고 이 클러스터 위에서 APP을 배포해보자.

 

이걸 이용해서 이제 도커가 왜 필요한지를 알아보자.

 

---

 

비슷한것으로

gcp gke를 확인해보자

 

안전한 완전 관리형(RDS) -> 서비스 요청시 즉시 서비스가 제공된다.(물리자원, OS, DB까지 포함해서 완성된 형태로 제공 - EKS, ECS)

 

---

 

먼저해야하는 것은 기존에 있던 가상머신을 삭제하는 것이다.

 

CentOS78을 지울려고 하는데... 가상머신의 스냅샷때문에 삭제 되지 않는다.

 

libvirt 자주 쓰는 명령어 정리 virsh (tistory.com)

libvirt 자주 쓰는 명령어 정리 virsh

 

참고로 이걸 사용해서 관리하자 가장 잘 정리되어 있다.

 

```

ovs-vsctl show

```

```

ovs-vsctl del-br vswitch03

```

으로 KVM1, KVM2모두 삭제해주자

 

---

 

예전에는 중소 규모에서는 가상화가 불가능했는데 2000년대 초반부터 AMD, Intel VT-x가 나오면서 CPU 가상화가 가능해졌다

 

가상화의 장점

1. 비용절감 -> 물리적인 서버 3대를 이용하여 운영하던 애플리케이션을 1대의 서버에서 논리적으로 3대의 서버를 생성하고 여기에 애플리케이션을 배포할 수 있게 됨으로써 비용을 절감.

 

2. 무중단 서비스 가능

-> Live Migration

 

3. 지역간 이동 가능

= 가용성 증대 (가상화가 클라우드에 도입될 경우 가용성은 99.9999%)

 

VMware Workstation : 개인용

- type 2

- 하이퍼바이저가 Host OS 상에 설치됨

 

VMware ESXi : 기업용

- type 1

- 하이퍼바이저가 커널상에 설치됨

 

BareMetal : 하드웨어 위에 하이퍼바이저가 바로 배치, 그 위에 Guest OS 그 위에 Application == VM

Host Based : HostOS위에 VMWare와 같은 애플리케이션 위에 VM이 올라가는 구조이다.

 

베어메탈 서버(Bare Metal Server)란? | 가비아 라이브러리 (gabia.com)

가비아 라이브러리

 

 

TYPE 1 에 해당하는 대표적인 하이퍼바이저

- ESXi(OS) -> VMKernel(하이퍼바이저)

- Linux -> KVM(하이퍼바이저)

 

 

 

하이퍼바이저를 이용하면 물리자원 - 하이퍼바이저 - [vResource - OS - App](VM)

각 가상머신들이 서버들이다. 두 서버간에는 관련이 없다. -> 가상화의 목적은 운영체제나 하드웨어 자원 풀을 공유하면서도 상호 의존성 없이, 타 응용 프로그램의 존재를 알 필요도 없이 여러 응용 프로그램을 실행할 수 있는 메커니즘을 제공 하는 것

 

가장큰 단점은 너무 무겁다. VM이 가상자원에 접근하려면 host kernel에 반드시 접근해야하기 허락과 접근과정이 일어나기 때문에 무거워진다.

 

가상머신에서 동작하는 애플리케이션은 두 개의 커널을 거쳐야 최종 물리 자원을 사용할 수 있으므로 성능저하는 필수요소이다.

 

물리자원위에 직접 배치된 애플리케이션에 비해 VM에서 동작하는 애플리케이션의 성능은 물리자원들의 성능은 평균적으로 30% 정도 성능저하가 발생.

성능정하를 감안해도 가상화를 통해 얻는 이점이 많아 도입

1. 사용자 입장에서는 애플리케이션이 물리서버위에 직접 배치되는 것과 가상머신에서 배치되는 것을 구분할 수 있나? -> 사용자 입장에서는 관심없음

사용자 입장에서는 애플리케이션의 빠른 성능만 관심대상

 

가상 머신은 격리도가 높고 자체적으로 완벽한 하나의 운영환경을 제공한다. 하지만, 가상의 하드웨어를 에뮬레이션 하는데 필요한 오버헤드로 인해 여전히 성능과 자원 에 대한 부담이 있다고 할 수 있다.

결국 성능저하가 일어나는 구간은 OS, vResource, Hypervisor들이다. 그래서 이걸 격리 시키자는 것이다.

 

기존에는 전체 VM을 격리했다면 지금은 App에서만 격리를 시키자는 것이다. 그럼 성능저하는 없다. 다만 이전에는 App안에 같은 소프트웨어를 여러번 설치해야한다.

 

이러한 환경을 컨테이너(Container)라고 부르며 응용프로그램을 그 안에서 독립적으로 실행할 수 있다.

 

컨테이너 기반의 가상화 : 컨테이너 내에 애플리케이션을 배치하고 컨테이너 형태 자체를 배포하여 각 애플리케이션에 대한 격리도를 높였다. 기존 가상화에 비해 보다 더 가벼운 격리도를 보일 수 있다.

 

애플리케이션 입장에서는 가상머신의 커널 -> 하이퍼바이저 -> 호스트 커널을 거치지 않고

직접적으로 호스트의 커널을 사용하므로 기존 일반 서버에서 운영하는 방식과 큰 차이가 없다

 

애플리케이션은 커널을 직접 접속할 수 있고 커널과 통신이 가능해야 하므로 커널은 오픈소스기반의 운영체제인 linux여야함. 또한 애플리케이션들도 리눅스 상에서 동작하는 애플리케이션 이어야 함.(책에 나오는 윈도우 상에 돌아가는 것들은 Linux VM위에서 도는 것이다)

 

운영체제 내에서 응용 프로 그램을 대상으로 폐쇄되고 제한되어 있는 분리된 환경을 제공하는 것이다. 이러한 환경을 컨테이너(Container)라고 부르며 응용프로그램을 그 안에서 독립적으로 실행할 수 있다.

컨테이너 화(Containerization) 컨테이너 기반 가상화를 가상 머신 기반 가상화와 구별하기 위해 때로는 가상화 대신 ‘컨테이너화’ 라는 용어를 사용한다

컨테이너에서는 독립된 응용프로그램을 별도의 게스트 운영체제 없이 실행할 수 있다.

가상화를 지원하는 기능은 응용프로그램 간의 격리를 커널 수준에서 지원하기 위한 노력에서 나온 직접적인 결과물이다.

이러한 밀접한 연관성으로 종종 컨테이너를 리눅스 컨테이너라고도 부른다. 하지만 모든 컨테이너가 LXC(Linux Container)는 아니다.

LXC 컨테이너는 격리된 환경을 제공한다. 하지만 컨테이너라는 단어의 또 다른 이면인 이동 성을 충족하기에는 부족하다. 이를 위해 도커가 탄생하였다. 도커는 컨테이너의 이동성과 패키징을 지원하기 위해 개발된 기술이다

시작

1. 리눅스 컨테이너                                          -> 컨테이너이동 -> Docker

- 네임스페이스 격리(Namespace Isolation)

네임스페이스 격리 또는 네임스페이스는 프로세스 상에서 사용하는 특정 자원에 대한 가시 성을 제한하기 위해 리눅스 커널에 구현된 기능이다. 별도의 네임스페이스를 사용하는 프로세스 간에는 서로의 자원을 볼 수 없도록 하는 것이다.

 

- 컨트롤 그룹(Control-group, Cgroup)

네임스페이스를 사용하는 아이디어는 시스템 자원에 대해 프로세스마다 다른 가시성을 제공 하는 것이다. 이를 통해 어느 정도의 격리는 제공하지만 그 자원들을 사용하는 것을 막지는 못한다.

Cgroup은 이러한 부분 또는 자원의 할당을 담당한다. Cgroup은 CPU, 메모리, 디스크I/O 등과 같은 자원을 제어하며 우선순위를 조정할 수 있고 자원의 사용을 제한할 수도 있다. 특정 프로세스에 대해 더 높은 수준의 CPU,메모리 할당을 할 수도 있으며 특정 프로세스가 사용하는 자원의 양을 모니터링 할 수도 있다.

 

이 두가지를 해서 도커에게 넘긴다.

 

2. 도커 컨테이너                         -> 컨테이너 오케스트레이션(쿠버네티스)

도커 외에도 컨테이너 기술이 존재

 

3. 쿠버네티스

쿠버네티스(구글 주도로 작성됨)는 애플리케이션 배포를 위해 runtime(도커)이 필요함. 명령을 받아 작업하게끔 만드는 것.

사실상 컨테이너 오케스트레이션의 표준이다.

 

도커는 자체적으로 오케스트레이션 툴이 있음(docker swarm)

 

하이퍼바이저는 독립적인 커널을 가지고 있다.

도커는 그렇지 못하기 때문에 완벽한 격리도를 보여줄 수 없다.

 

예를 들어 동일한 애플리케이션을 다수 운영하는 회사 => container

고객에게 별도의 운영체제와 사용환경, 볼륨을 제공하고 싶다 => hypervisor

 

둘을 동일선상에서 비교하면 안된다.

 

 

 

 

실습

우분트를 넣어주자

 

.

이건 OS에 들어가는게 아니니 그냥 test로 퉁치자

 

VM 설정에서 가상화를 체크할 필요가 없어졌다

autoinst를 지우자

 

마지막으로 네트워크 설정을 해주고 그외 쓸모없는것들을 지우자

 

Install Ubuntu -> continue

minimal installation

재시작하자

 

 

들어가서 바탕화면 - settings를 누르자

 

네트워크가 3점대로 들어온것을 확인할 수 있다.

 

터미널 가서

```

sudo passwd root

user1

test123

 

su root

test123

```

```

vi ~/.bashrc

```

에다가 아래와 같이 vim을 alias로 잡아놓자

이제 user1을 이용하여 docker 실습 진행

sudo를 이용하여 루트의 권한을 일시적으로 얻어와야 함

 

```

usermod -aG sudo user1

vi /etc/sudoers

```

들어가서 usr1에게 모든 명령어 실행권한을 주자

 

이제 user1 유저 상태에서 다음 명령어들을 입력해보자

sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
apt-cache policy docker-ce
sudo apt install -y docker-ce
sudo systemctl status docker
sudo systemctl enable docker

sudo apt-get install -y ssh

sudo systemctl start docker
sudo systemctl enable docker
sudo systemctl status docker

docker -v

하긴했는데 계속 sudo를 쓰기 귀찮다. 그래서 user1이 docker을 쓸때만큼은 sudo를 쓰지 않아도 되게끔 만들어보자.

 

user1을 docker 그룹에 넣어보자

sudo usermod -aG docker user1
groups

su user1
groups user1

 

스냅샷도 찍어놓자

 

도커 라이프사이클 관리

 

도커는 컨테이너 안에 App을 넣는다. 이 안에 들어갈 수 있는건 App과 OS이다.

이 컨테이너를 만들기 위해서는 BaseImage가 필요하다.

 

aws에도 인스턴스를 만들면 볼륨을 baseImage로 만들었다. 그리고 이 Image로 인스턴스를 만들었다. 그래서 이 이미지 안에 우리가 원하는 것을 모두 설치할 수 있었다. 그리고 똑같은 것을 여러개로 복사해서 사용하는 방법이었다. 도커도 이와 유사하다.

 

도커도 BaseImage를 가져다가 컴퓨터에 가져오고 이를 로컬저장소라소라고 부른다. 처음에는 BaseImage가 모여있는 docker hub에서 가져온다.

 

이걸 가져오기 위한 docker hub, 원격저장소가 따로 존재한다. 원격에서 public repo(접근 제한 X)와 private repo(접근 제한 O - 계정)가 존재한다.

public은 접근제한 없이 누구든지 다운받아 사용할 수 있고 private는 접근제한이 있다.

 

 

 

 

로컬저장소에는 이미지가 있어서 private 저장소에 넣어놓는다면 인터넷 연결없이 사용할 수 있게 된다.

 

이제 우리가 사이트를 만들어서 배포를 한다고 할때 모든 데이터를 로컬저장소에 저장할 수 없다. 여러 사람이 코드를 저장할 수 있는 원격 저장소가 별도로 필요해진다. (pub/pri) 저장소가 별도로 필요하다. 다만 팀이 아닌 타인이 들어올 수 없도록 private 원격 저장소를 따로 만들어 두어야 한다.

그렇다고 private가 항상 원격에서만 접속할 수 있는건 아니다. 우리가 따로 사설 저장소를 회사내에 만들어서 사용할 수도 있다.

 

컨테이너 배포는 base 이미지에 필요한 내용을 추가하여 커스텀 이미지를 제작하고 해당 이미지를 컨테이너 형태로 배포하게된다.

이미지의 보관은 로컬저장소, 원격저장소로 구분하며 원격저장소는 public 저장소, private 저장소로 구분된다.

public 저장소는 접근에 제한이 없으므로 이미지의 이름만 알고 있다면 다운로드하여 사용가능하다.

private 저장소는 반드시 인증을 통해 접근할 수 있다. 따라서 회사내에 필요한 프로젝트가 진행될 경우에는 private 저장소를 인터넷이나 회사 내부의 서버에 구축한 뒤 이를 활용하여 프로젝트가 진행됨.

 

대표적인 public 저장소 -> docker hub

대표적인 private 저장소 -> docker hub, aws, gcp, azure, 로컬환경(회사내)에 설치형으로 설치한 뒤 사용할 수 있는 "private registry"도 있다. 인증요함

 

컨테이너 배포의 일반적인 형태는 다음과 같다.

 

Docker-hub에는 이미 공개된 이미지(public)가 있다. 그리고 우리 PC 로컬저장소에는 httpd로 배포할 데이터들이 있다.

그래서 원격에서 이미지를 pull(받아옴)해서 로컬저장소에 담고 담긴 local 저장소를 컨테이너 배포한다

 

그럼 도커허브가 있고 없고의 차이가 무엇인가?

도커허브는 ip의 1일 다운로드 제한이 100개이다.

 

원활한 실습을 위해서는 docker-hub에 계정을 만들어 두어야 함. 계정을 생성하면 docker-hub에 자신만의 저장소(public, private)를 만들 수 있다.

참고로 private 저장소는 1개 만들 수 있다.

 

Docker Hub Container Image Library | App Containerization

Docker Hub Container Image Library | App Containerization

위 사이트에 가입해서 docker private remote를 하나 가지고 있자

 

이제 실재 컨테이너를 만들어보자

```

docker search centos:7

```

몬가... 이상한게 드럽게 많다

이건 사용자의 이미지이다.

 

```

docker search centos

```

보면 이렇게 검색시 '/'가 없는것도 있다.

docker search 했을 때 결과중에 /가 없는 이미지는 도커에서 제작하여 올린 base 이미지이다. 그리고 /앞쪽에 있는 것은 업로드한 사용자계정이다.

 

한번 사용해보자

```

docker pull centos:7

```

도커 허브에 공개된 이미지중에서 centos 버전이 7인 기본이미지를 로컬 저장소로 복사함(pull 함)

이때

```

docker pull centos

```

와의 차이점은 ':' 다음의 번호는 tag라고 하며 일반적으로 버전으로 사용됨. 만약 tag를 표기하지 않으면 도커 허브에 있는 centos 중에서 최신 이미지를 pull하게 됨.

 

```

docker image ls

```

내가 받은 도커 이미지들을 확인할 수 있다.

 

```

docker pull httpd

```

httpd도 받아놓자

 

 

centos를 ubuntu 위에 배포하기 전에 지금 쓰는 것의 커널 버전도 확인해보자

 

```

docker container run -it --name centos01 --hostname centos1 centos:7 /bin/bash

```

 

centos 환경으로 바뀌었다... 다운로드과정도 없었다...

 

우린 어디에 있는가

 

가장 아래에 Physical Resource가 있고

위에 OS(ubuntu + kernel)이 있고

위에 docker가 있고

그 바로 위에 컨테이너가 있다. 그런데 여기의 컨테이너가 centos이다.

 

그런데 우리가 받은 이미지는 커널이 없어서 centos에서 일을 처리하기 위해서는 아래쪽에 OS(ubuntu)의 kernel을 써야한다.

 

(ctrl + p, ctrl + q)

를 순서대로 눌러주자

빠져나왔다.

 

```

docker container run -it --name centos02 --hostname centos2 centos:7 /bin/bash

docker container ls

```

하면 위와같이 현재 화면에 내가 생성했던 컨테이너들을 볼 수 있다.

 

"--name" 은 도커가 관리하는 컨테이너의 구분자 이름. 관리를 위한 목적으로 사용되므로 절대 겹처서는 안됨.

"--hostname"은 생성된 컨테이너 내에서 사용하는 호스트 이름

 

```

docker container rm [컨테이너 이미지]|[컨테이너 ID]

```

 

하면 바로 삭제가 안되어서 f 플레그를 넣어주어야 한다.

```

docker container rm -f centos02

```

이번에는 httpd를 동작시키어보자

 

```

sudo docker login

cat /root/.docker/config.json

```

```

docker container run -d -p 8001:80 httpd

```

 

놀랍게도 웹서버가 돌아간다.

 

이건 우분트에서 8001 혹은 8002 번 포트를 타고 docker 컨테이너의 80번 포트로 들어가 서비스를 받았기 떄문에 가능했던 일이다.

 

이제 이것들을 한번에 지워보자

그냥 하면 시간이 오래걸리기 때문에

```

docker container ls -aq  #전체 리스트들의 id값만 보인다

docker container rm -f $(docker container ls -aq)  # 전체 컨테이너를 삭제할 수 있다.

```

 

---

 

자주쓰는 명령어들을 정리해보자

 

# 로컬 저장소에 있는 이미지 리스트

docker image ls

 

# 이미지중 centos 7버전 삭제

docker image rm centos:7

 

# 이미지중 centos 최신버전 삭제

docker image rm centos

 

# 해당 이미지를 이용하여 동작중인 컨테이너가 있을 경우에는 이미지가 삭제되지 않는다. 이 경우 강제로 이미지를 삭제하고 싶다면? -f

 

도커사용하는 방법

1. docker image pull을 이용하여 허브에 있는 base 이미지를 로컬 저장소로 pull 한다.

2. docker container create 를 하면 컨테이너가 생성만된다.

docker container run을 하면 생성한 뒤, 실행까지 시킴

 

3. 동작중인 컨테이너는 restart를 통해 재부팅, pause를 통해 일시중지/unpause를 통해 일시중지해제가 가능하다.

 

4. docker container stop을 통해 중지시킬 수 있다.

5. 삭제는 docker container rm을 이용할 수 있으며 동작중인 상태에서의 삭제는 -f 옵션을 이용하거나 stop후에 삭제해야 함.

* 만약 docker container run을 하면, 도커는 컨테이너 생성을 위해 로컬 저장소에서 해당 이미지의 이름을 갖는 이미지를 찾는데 없다면?

docker container run -it --name --hostname centos:7 /bin/bash

자동으로 도커 허브에서 이미지를 끌고와서 다운받고 실행시켜줌

 

이때

-i 옵션 : 사용자로부터 입력을 받아 처리할 수 있음

-t 옵션 : tty 터미널을 의미. 마치 ssh로 연결하여 사용하는 것처럼 세션을 제공

/bin/bash : -i로 사용자로부터 입력받음. 어떠한 방법을 이용할 것인가를 의미하여 이는 컨테이너의 bash로 연결하여 입력하겠다는 뜻이다.

--name : 도커가 컨테이너를 관리하기 위한 이름

--hostname : 생성된 컨테이너 내에서 사용하는 hostname

 

위의 방법을 이용하면 마치 ssh를 이용하여 컨테이너에 연결하는 효과를 볼 수 있다. 만약 컨테이너에서 벗어나고 싶다면?

1. ctrl + c | exit-> 컨테이너를 중지시키고 빠져나옴

2. ctrl + p, ctrl + q -> 컨테이너가 백그라운드에서 여전히 동작중이다

 

```

docker container attach 컨테이너명  # 컨테이너 재실행

```

 

```

docker container run -d -p 8001:80 httpd

```

-d : 해당 컨테이너를 외부와 직접 연결하지 않고 백그라운드에서 서비스를 제공

-p 8001:80 : 포트포워딩을 의미하며 호스트(ubuntu)의 8001번 포트로 접속하면 컨테이너의 80번 포트로 접속되도록 포워딩 해줌

 

```

docker search mariadb

```

 

중요한 옵션중에 restart라는 것이 있다. 이건 실패할때마다 재시도하는 옵션이다.

 

--restart=on-failure:3  -> 컨테이너를 처음 시작할 때 문제가 발생하여 정상 실행되지 않는다면 3번까지 재부팅하며 실행을 시도하고 그 이후에도 정상실행되지 않는다면 이때는 fail(stop 상태에 머뭄)

 

이번에는 nginX를 사용해보자

 

```

docker container run -d -p 8888:80 -v /home/user1/html:/usr/share/nginx/html nginx 

```

-v (--volume) : 마운트(NFS)와 volume(iSCSI) 을 사용할 수 있다. 현재 옵션에서는 호스트(ubuntu)의 /home/user1/html과 컨테이너의 /usr/share/nginx/html이 마운트되어 있다는 의미이다.

결국, nginx의 기본 홈 디렉토리는 /usr/share/nginx/html 이라는 뜻 -> 이렇게하면 로컬에 저장한 파일을 docker로 구동중인 nginx에 넣을 수 있다.

 

결과 위와같다.

 

보면 위와같이 vm의 디렉토리를 nginx에 마운트해서 사용하게 된다.

 

-v는 볼륨을 의미

1) mount, nfs (file storage)

마운트는 우분투의 특정 디렉토리와 컨테이너의 특정 디렉토리르 연결하는 방법

```

docker container run -d -p 8888:80 -v /home/user1/html:/usr/share/nginx/html nginx 

```

 

2) disk를 제공 (block storage)

스토리지에서 볼륨을 생성하고 해당 볼륨을 컨테이너에 디스크 형태로 부착하는 방법

이걸 활용해서 aws의 Disk를 EC2에 블록 스토리지로 제공할 수도 있게 된다.

 

이번에는 볼륨을 만들고 해당 볼륨을 컨테이너에 연결하여 사용하는 방법

 

```

docker volume create --name testvol

docker volume ls

 

docker container run -it -v testvol:/root centos:7 /bin/bash

```

하면 testvol이 root 디렉토리로 들어가게 된다.

 

docker이미지에서 파일을 생성하고 잠깐 멈추어보자

 

새로운 도커이미지를 생성했는데 놀랍게도 우리가 만든 파일이 있다.

 

이러한 방식으로 우리는 공유 공간 볼륨을 생성하고 끼워넣을 수도 있다.

 

```

docker container run -d --name wordpressdb -e MYSQL_ROOT_PASSWORD=test123 -e MYSQL_DATABASE=wordpress mysql:5.7

docker container run -d -e WORDPRESS_DB_PASSWORD=test123 --name wordpress --link wordpressdb:mysql -p 8881:80 wordpress

```

몬가 DB랑 연결이 잘 안된다. 암튼 이런식으로 WORDPRESS를 DB랑 연결해 배포해볼 수도 있다.

 

```

docker container run -d --name wordpressdb -e MYSQL_ROOT_PASSWORD=test123 -e MYSQL_DATABASE=wordpress mysql:5.7

docker container run -d --name wordpress --link wordpressdb:mysql -p 8881:80 wordpress

```

 

최종적으로 잘 뜬다.

 

블로그가 만들어진것을 확인할 수 있다.

 

이미지 만들기(중요)

이제부터 우리가 직접 이미지를 만들어서 docker hub에 올리는 일을 해보자.

 

Mariadb - Official Image | Docker Hub

Mariadb - Official Image | Docker Hub

설치시 상세한 버전과 설정은 위의 링크로가서 직접 찾아봐야한다.

 

```

docker pull mariadb:10.4

sudo apt-get install -y mariadb-client

```

 

Quiz. 다음의 조건에 부합하는 mariadb 컨테이너를 제공하세요.

외부(ubuntu)에서 다음과 같이 접속할 수 있어야 한다.

 

mysql testdb -u root -ptest1234 -h 211.183.3.200:33060

 

```

docker container run -d --name testdb -p 33061:3306 -e MARIADB_ROOT_PASSWORD=test1234 -e MARIADB_DATABASE=testdb -e MARIADB_ROOT_HOST=localhost mariadb:10.4

mysql testdb -u root -ptest1234 -h 211.183.3.200 -P 33060

```

 

잘된다