chromedriver가 포함된 파이썬으로 개발한 프로그램을 실행파일로 만드는 방법입니다. 

 

 

1. pyintaller 설치

파이썬으로 개발한 프로그램을 실행파일로 만들기 위한 도구인 pyinstaller 를 설치합니다.

pip install pyinstaller

 

2. chromedriver 추가

chromedriver를 사용하여 자동 스크롤링이나 웹화면을 호출하는 경우에 chromedriver가 필요한데, 아래는 chromedriver를 추가한 프로그램입니다.

아래처럼하면 현재 OS에 설치된 크롬브라우저의 버전에 맞는 chromedriver를 다운로드하여 사용합니다.

chrome_options = webdriver.ChromeOptions()
chrome_options.add_experimental_option('excludeSwitches', ['enable-logging'])
driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()), options=chrome_options)
driver.maximize_window()

chrome_options.add_experimental_option('excludeSwitches', ['enable-logging'])

## 실행시 아래 오류 발생 방지 : 실행 시 아래 오류가 발생하는데 이를 방지하기 위한 부분
## USB: usb_device_handle_win.cc:1048 Failed to read descriptor from node connection: 시스템에 부착된 장치가 작동하지 않습니다. (0x1F)

## C:\Users\[사용자]\.wdm\drivers\chromedriver\win32\[크롬버전]110.0.5481 디렉토리 경로에 chromedriver.exe 파일이 다운로드됩니다.

예) 사용자가 admin이고 크롬버전이 110.0.5481인 경우 C:\Users\admin\.wdm\drivers\chromedriver\win32\110.0.5481 디렉토리 경로에 chromedriver.exe 파일이 다운로드됨

 

3. 실행파일 생성

sysntax : pyinstaller <python-file> --onefile --noconsole --add-binary  "<chromedriver.exe>;."

<python-file> : 실행파일을 만들고자 하는 python 파일명(파일 위치를 지정할 수 있음)

<chromedriver.exe> : chromedriver.exe 파일의 위치와 chromedriver.exe 파일명(파일 위치를 지정할 수 있음)

pyinstaller daum_login.py --onefile --noconsole --add-binary  "chromedriver.exe;."

[optioins]

--onefile : 하나의 실행파일을 생성

--noconsole : 실행파일을 실행 시 콘솔에 메시지를 출력하지 않습니다.

--add-binary : 소스위치:포함위치(chromedriver.exe;. -> chromedriver.exe 파일을 현재 디렉토리에 포함하라는 의미). linux/linux인 경우에는 세미콜론(;) 대신 콜론 문자(:)를 사용

--add-file : 소스위치:포함위치(README;. -> README 파일을 현재 디렉토리에 포함)

 

기타 옵션은 아래 URL 참조

https://pyinstaller.org/en/stable/usage.html

pyinstaller로 컴파일하면 아래와 같은 구조의 디렉토리가 생성됩니다.

dist 디렉토리에 실행파일이 생성됩니다.

C:.
├─build
│  └─daum_login
├─dist
└─__pycache__

 

4. 예제 프로그램

아래 예제는 daum에 자동 로그인하는 프로그램 예제입니다. daum 계정이 있으면 아래 내용 중 <daum 계정ID>, <계정 패스워드> 부분을 본인의 계정/패스워드로 수정하면 자동 로그인할 수 있습니다.

- 파일명 : daum_login.py

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.options import Options
import time

chrome_options = webdriver.ChromeOptions()
chrome_options.add_experimental_option('excludeSwitches', ['enable-logging'])
driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()), options=chrome_options)
driver.maximize_window()

driver.get("https://logins.daum.net/accounts/signinform.do?url=https%3A%2F%2Fwww.daum.net")

## ID/Password 입력
elem = driver.find_element(By.NAME, "id")
elem.send_keys("<daum 계정ID")
elem = driver.find_element(By.NAME, "pw")
elem.send_keys("<계정 패스워드>")

## login 버튼클릭
login_btn=driver.find_element(By.ID, "loginBtn");
login_btn.click();

# 프로그램 실행 후 화면을 10초가 유지
time.sleep(10)

아래와 같이 2가지 방법 중 하나로 컴파일합니다.

## 현재 디렉토리에서 컴파일하는 방법(단, chromedriver.exe는 py 파일과 같은 폴더에 있어야 함)
## 위의 chromedriver.exe 다운로드 경로에서 복사하여 붙여넣기한다.
pyinstaller daum_login.py --onefile --noconsole --add-binary  "chromedriver.exe;."

## 전체 경로를 지정한 컴파일 방법
## py 파일이 C:\python_project\에 있고 chromedriver.exe 파일이 C:\python_project 에 있을 때
## py 파일과 chromedriver.exe 파일 위치는 각자의 위치로 지정
pyinstaller C:\python_project\daum_login.py --onefile --add-binary  "C:\python_project\chromedriver.exe;."

 

컴파일한 디렉토리 하위에 dist 폴더가 생성됩니다. 이 폴더에 실행파일이 생성됩니다.

예제에서는 C:\python_project\dist 폴더에 daum_login.exe 실행 파일이 생성됩니다.

 

<참고> 

실행파일을 실행한 후 실행이 종료되면 브라우저가 종료되는데 이를 방지하기 위한 방법으로 아래 내용을 추가했으나, 작동하지 않고 프로그램이 종료됨. 

chrome_options.add_experimental_option('detach', True) 

 

from seleniumwire import webdriver
seleniumwire 로 webdriver를 설정했으나, 역시 프로그램이 종료됨.

리눅스 서버 재부팅 시 Linux 서비스 자동 기동 설정 방법

많은 방식이 있지만 주로 사용되는 2가지 방식 중 최신에 많이 사용되는 설정 방법을 설명합니다.

 

자동기동 방법

1) init 데몬 및 런레벨로 설정

2) systemd의 서비스로 설정

최신 Linux init 데몬은 systemd입니다. systemd는 현대 Linux 시스템의 많은 구성 요소를 포함하는 프레임워크입니다.
그 기능 중 하나는 Linux용 시스템 및 서비스 관리자로 작동하는 것입니다.
systemd는 System V 명령 및 초기화 스크립트와 역호환됩니다. 이는 모든 System V 서비스가 systemd에서도 실행됨을 의미합니다. 이는 대부분의 Upstart 및 System V 관리 명령이 systemd에서 작동하도록 수정되었기 때문에 가능합니다.

 

systemd Configuration Files: Unit Files

systemd의 핵심은 단위 파일입니다. 각 단위 파일은 특정 시스템 리소스를 나타냅니다. 리소스에 대한 정보는 단위 파일에서 추적됩니다. 서비스 단위 파일은 선언적 구문이 있는 단순한 텍스트 파일(Upstart .conf 파일과 같은)입니다.
systemd와 init 방법의 주요 차이점은 systemd는 서비스 데몬 및 장치 운영 체제 경로, 마운트 지점, 소켓 등과 같은 다른 유형의 리소스 초기화를 담당한다는 것입니다. 단위 파일의 이름 지정은 service_name.unit_type 형식입니다.

dbus.service, sshd.socket 또는 home.mount와 같은 형식의 파일입니다.

 

Directory Structure

CentOS와 같은 Red Hat 기반 시스템에는 단위 파일은 두 위치에 있습니다. 기본 위치는 /lib/systemd/system/입니다. 시스템 관리자가 수정한 사용자 지정 단위 파일 또는 기존 단위 파일은 /etc/systemd/system 아래에 있습니다.

동일한 이름의 단위 파일이 두 위치에 모두 존재하는 경우 systemd는 /etc 아래에 있는 파일을 사용합니다. 서비스가 부팅 시 또는 다른 대상/런레벨에서 시작되도록 활성화되어 있다고 가정합니다. 이 경우 /etc/systemd/system의 해당 디렉토리 아래에 해당 서비스 단위 파일에 대한 심볼릭 링크가 생성됩니다. /etc/systemd/system 아래에 있는 단위 파일은 실제로 /lib/systemd/system 아래에 같은 이름을 가진 파일에 대한 심볼릭 링크입니다.

 

systemd init Sequence: Target Units

단위 파일의 특별 유형은 target unit입니다.
대상 단위 파일 이름에는 .target이 접미사로 붙습니다. 대상 단위는 하나의 특정 리소스를 나타내지 않기 때문에 다른 단위 파일과 다릅니다. 대상 단위는 특정 시정의 시스템 상태를 나타냅니다. 

 

각 대상에는 번호 대신 이름이 있습니다. 예를 들어, runlevel 3 대신 multi-user.target이 있거나 runlevel 6 대신 reboot.target이 있습니다. Linux 서버가 multi-user.target으로 부팅할 때 본질적으로 서버를 실행 수준 2, 3 또는 4로 가져옵니다. 네트워킹이 활성화된 다중 사용자 텍스트 모드입니다.

 

Runlevel (System V init)Target Units (Systemd)

runlevel 0 poweroff.target
runlevel 1 resuce.target
runlevel 2, 3, 4 multi-user.target
runlevel 5 graphical.target
runlevel 6 reboot.target

systemd default.target

systemd default.target은 System V 기본 실행 수준과 동일합니다.

System V에는 inittab이라는 파일에 정의된 기본 실행 수준이 있습니다. systemd에서 해당 파일은 default.target으로 대체됩니다. 기본 대상 단위 파일은 /etc/systemd/system 디렉토리에 있습니다. /lib/systemd/system 아래의 대상 단위 파일 중 하나에 대한 심볼릭 링크입니다.

 

systemd Dependencies: Wants and Requires

systemd Wants and Requires는 서비스 데몬 간의 종속성을 제어합니다.

System V에서 서비스는 특정 실행 수준에서 시작될 수 있지만 다른 서비스나 리소스를 사용할 수 있을 때까지 기다리도록 만들 수도 있습니다. 비슷한 방식으로 systemd 서비스는 하나 이상의 대상에 로드하거나 다른 서비스나 리소스가 활성화될 때까지 기다릴 수 있습니다.

 

systemd에서 다른 장치가 필요한 장치는 필요한 장치가 로드되고 활성화될 때까지 시작되지 않습니다. 첫 번째 장치가 활성화된 동안 필요한 장치가 어떤 이유로 실패하면 첫 번째 장치도 중지됩니다.

이것은 시스템 안정성을 보장합니다. 따라서 특정 디렉토리가 있어야 하는 서비스는 해당 디렉토리에 대한 마운트 지점이 활성화될 때까지 대기하도록 만들 수 있습니다. 

 

Practical Example: Understanding the systemd Startup Sequence

아래 명령을 실행하여 기본 대상 단위 파일을 나열합니다.

sudo ls -l /etc/systemd/system/default.target

기본 대상은 /lib/systemd/system/ 아래의 다중 사용자 대상 파일에 대한 심볼릭 링크입니다. 따라서 시스템은 System V init의 런레벨 3과 유사한 multi-user.target에서 부팅됩니다.

multi-user.target.wants

Next, let’s run the following command to check all the services the multi-user.target file wants:

모든 서비스의 multi-user.target wants를 확인하기 위해 다음 명령을 실행합니다.

sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service

/usr/lib/systemd/system/ 아래의 실제 유닛 파일을 가리키는 심볼릭 링크 파일 목록을 보여줍니다.

multi-user.target 외에도 system-update.target 또는 basic.target과 같은 다양한 유형의 대상이 있습니다.

다중 사용자 대상이 의존하는 대상을 보려면 다음 명령을 실행합니다.

sudo systemctl show --property "Requires" multi-user.target | fmt -10

basic.target

다음 명령을 실행하여 basic.target에 필요한 단위가 있는지 확인할 수 있습니다.

sudo systemctl show --property "Requires" basic.target | fmt -10

그리고 몇 가지 targets 을 필요로 합니다.

sudo systemctl show --property "Wants" basic.target | fmt -10

 

재귀적으로 진행하면 sysinit.target이 다른 대상도 실행해야 하는지 확인할 수 있습니다.

sudo systemctl show --property "Requires" sysinit.target | fmt -10

sysinit.target이 원하는 다른 타겟이 있을 수 있습니다.

systemctl show --property "Wants" sysinit.target | fmt -10

Examining a systemd Unit File

sshd용 서비스 단위 파일을 살펴보겠습니다.

sudo vi /etc/systemd/system/multi-user.target.wants/sshd.service

## sshd.service 파일 내용
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

첫 번째 부분은 [Unit] 섹션의 After 절입니다. 이것은 network.target 및 sshd-keygen.target이 로드된 후 sshd 서비스를 로드해야 한다는 것을 의미합니다.

[Install] 섹션은 multi-user.target이 원하는 서비스를 보여줍니다. 이것은 multi-user.target이 sshd 데몬을 로드하지만 로드하는 동안 sshd가 실패하면 종료되거나 충돌하지 않는다는 것을 의미합니다.

multi-user.target이 기본 대상이므로 sshd 데몬은 부팅 시 시작되어야 합니다. [Service] 섹션에서 Restart 매개변수에는 on-failure 값이 있는데 이 설정을 사용하면 sshd 데몬이 충돌하거나 비정상 종료가 있는 경우 다시 시작할 수 있습니다.

 

서비스 자동기동 설정 예제

특정 작업을 하는 쉘 프로그램을 서비스로 등록하여 자동 기동되도록 설정해 보겠습니다.

  1. 실행가는한 쉘 프로그램(예: myservice.sh)
  2. 스크립트를 실행하는 명령이 포함된 644 권한이 있는 /etc/systemd/system의 ".service" 확장자가 있는 단위 파일(예: myservice.service)

: myservice.sh

echo "Service starting time is : " `date` >> myservice_start.log

 

 

: myservice.service

[Unit]
Description=Example systemd service.

[Service]
Type=simple
ExecStart=/bin/bash /home/user/myscript.sh

[Install]
WantedBy=multi-user.target
  1. Run the command sudo systemctl enable myservice to enable it to start on boot.

 

sudo systemctl daemon-reload

sudo systemctl enable myservice
sudo systemctl start myservice
cs

 

  서비스가 제대로 실행이 되었는지 상태를 확인하기 위해선 아래처럼 실행한다.

1
sudo systemctl status myservice

 

 

 

Docker 엔진은 어떻습니까?

"containerd로 전환하면 더 이상 Docker 엔진을 사용할 수 없습니까?" 우리는 이 질문을 많이 듣습니다. 짧은 대답은 NO입니다.

Docker 엔진은 containerd 위에 구축됩니다. Docker Community Edition(Docker CE) 의 다음 릴리스는 containerd 버전 1.1을 사용합니다. 물론 CRI 플러그인이 내장되어 있고 기본적으로 활성화되어 있습니다. 즉, 사용자는 Docker 사용자에게 일반적인 다른 용도로 Docker 엔진을 계속 사용할 수 있으며, 동일한 노드에서 Docker 엔진과 함께 제공되고 동시에 사용되고 있는 기본 컨테이너를 사용하도록 Kubernetes를 구성할 수도 있습니다. Docker Engine 및 Kubelet에서 사용되는 동일한 containerd를 보여주는 아래 아키텍처 그림을 참조하십시오.

Containerd는 Kubelet과 Docker Engine 모두에서 사용되기 때문에 containerd 통합을 선택하는 사용자는 새로운 Kubernetes 기능, 성능 및 안정성 향상을 얻을 뿐만 아니라 다른 사용 사례를 위해 Docker Engine을 유지하는 옵션도 갖게 됩니다.

 

Containerd 네임스페이스 메커니즘은 Kubelet과 Docker Engine이 서로 생성한 컨테이너와 이미지를 보거나 액세스할 수 없도록 보장하기 위해 사용됩니다. 이렇게 하면 서로 간섭하지 않습니다. 이것은 또한 다음을 의미합니다.

  • 사용자는 docker ps 명령 을 사용하여 Kubernetes에서 만든 컨테이너를 볼 수 없습니다 . 대신 crictl ps 를 사용하십시오 . 그 반대의 경우도 마찬가지입니다. 사용자는 Kubernetes에서 또는 crictl ps 명령을 사용하여 Docker CLI가 생성한 컨테이너를 볼 수 없습니다. crictl create 및 crictl runp 명령은 문제 해결용입니다. 프로덕션 노드 에서 crictl 을 사용하여 포드 또는 컨테이너를 수동으로 시작하는 것은 권장되지 않습니다.
  • 사용자는 docker images 명령 을 사용하여 Kubernetes에서 가져온 이미지를 볼 수 없습니다 . 대신 crictl 이미지 명령을 사용 하십시오 . 그 반대의 경우도 마찬가지입니다. Kubernetes는 docker pull , docker load 또는 docker build 명령으로 생성된 이미지를 볼 수 없습니다. 대신 crictl pull 명령을 사용 하고 이미지를 로드해야 하는 경우 ctr cri load 를 사용하십시오.

 

최신 Docker 설치는 컨테이너 관리를 담당하는 containerd와 나머지 모든 작업을 담당하는 dockerd의 두 가지 서비스로 나뉩니다 .

 

OCI 표준은 다양한 컨테이너 솔루션 간의 상호 운용성을 가져왔습니다. 결과적으로 한 시스템에 구축된 이미지는 다른 호환 스택에서 실행할 수 있습니다.

여러 호스트를 이용하는 도커가 swarm을 이룰경우 서로 통신을 하려면 네트웍이 필요하다. 이때 각각 다른 호스트에서 생성된 컨테이너 사이에 네트워크를 생성해주는 것이 바로 overlay 네트워크 이다.

 

각각의 호스트에서 쓰고있는 네트워크와 상관없이 컨테이너 끼리의 사설망을 따로 만들어줌.

 

 

Docker Swarm 을 구성해놓은 상태에서 새로

 

overlay 네트워크 생성하고 테스트해보기.

Docker Swarm 을 구성

Docker Swarm은 여러가지 컨테이너 오케스트레이션 툴(가장 대표적인 것이 kubernetes임) 중 하나이다.

Docker Swarm에서 제어하는 단위는 컨테이너가 아닌 "service" 이다. (쿠버네티스의 pod와 같다고 생각하면 됨)

1. Swarm manager 설정

Swarm 클러스터에서 manager 역할을 할 노드를 선정한다. 여기서는 "swarm-manager" 로 선택했다. 아래 init 명령을 swarm-manager에서 수행한다. --advertise-addr은 manager 역할을 하는 IP를 입력한다. 즉 swarm-manager의 IP를 입력한다. 

docker swarm init --advertise-addr 10.10.1.39

To add a worker to this swarm, run the following command:
    docker swarm join --token SWMTKN-1-1e2cs4etdsl1yo7yclq5rdngheo6f3yecy0gc1wnt03fyrt1yd-1taof5n1m6zmbtenuysd5q60a 10.10.1.39:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

결과 중 docker swarm join --token 부분은 연결을 위한 비밀키가 생성된 것이다. 복사하여 각 노드들이 docker swarm 클러스터에 조인하도록 사용한다. 

 docker swarm join --token SWMTKN-1-1e2cs4etdsl1yo7yclq5rdngheo6f3yecy0gc1wnt03fyrt1yd-1taof5n1m6zmbtenuysd5q60a 10.10.1.39:2377
 
 This node joined a swarm as a worker.

 

docker swarm init과 join을 수행하면 docker network 에 ingress와 docker_gwbridge 네트워크가 추가된다.

 

 

 

2. 노드 조인 및 확인

위에서 manager node에서 아래 명령어를 수행하면 도커 스웜 클러스터에 참여한 node를 확인할 수 있다.

docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
q9d7qflcsd1nvoy9291v7vhcz *   swarm-manager     Ready     Active         Leader           20.10.17
mllks5805fyeoake38u6d2nfa     swarm-node-1      Ready     Active                          20.10.17

 

1.network 생성

overlay 네트워크 생성 및 확인

 

$ docker network create --driver=overlay --subnet=192.168.0.0/24 my-overlay

$ docker network ls
NETWORK ID     NAME              DRIVER    SCOPE
c09c209df657   bridge            bridge    local
bf717637be38   docker_gwbridge   bridge    local
156d020c1e52   host              host      local
knzfg8g8u065   ingress           overlay   swarm
fadlzyj565he   my-overlay        overlay   swarm
d3cd7692e4cb   none              null      local

도커 스웜 서비스 생성

$ docker service create --name overlaysvc --network my-overlay --replicas 3 hello-world 

**3.네트워크 테스트** 

master노드에서 ps 실행 및 ip 확인

https://kubernetes.io 의 document 만을 참고하여 문제를 풀 것.

사전에 auto completion 을 설정되어 있으므로 잘 활용하면 효율적임.

tmux 도 제공되므로 활용하면 좋음.

문제 지시에 따라 context 를 지정한 후 문제를 푼다.(sudo -i 를 한경우 반드시 context를 확인해야 함)

sudo -i 를 사용해야 할 경우도 있음.  --> sudo 명령어를 사용하는게 나을 듯.

 

시험전략

- 시험전에 pc compatibility 체크

- 74점 이상이므로 너무 어려운 문제를 풀려고 하지 말것.

- 최신 버전으로 시험 준비

- CKA portal : 

 

 

 

 

 

24 or 28 문제 출제??

 

시험 환경 설정

🔒 kubectl autocompletion 하기

 

echo 'source <(kubectl completion bash)' >>~/.bashrc

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc

source .bashrc

예상 시험 문제

🔒 kubeadm으로 클러스터 구성하기

 

1. container runtime 설치

: kubernetes.io 사이트에서 "container runtime" 로 검색 한 후 "container runtimes" 클릭 후 설정

sudo modprobe br_netfilter

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

apt install containerd

2. container runtime 설치

: kubernetes.io 사이트에서 "install with kubeadm" 로 검색 한 후 설정

apt 패키지를 업데이트하고 ubernetes apt저장소를 사용하는 데 필요한 패키지를 설치한다.

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

Google Cloud 공개 서명 키를 다운로드

sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

Kubernetes apt 리포지토리를 추가

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

패키지 인덱스를 업데이트 apt하고 kubelet, kubeadm 및 kubectl을 설치하고 해당 버전을 고정

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

 

3. control-plane node 초기화

$ kubeadm init
...

## 완료가 되면 아래와 같은 메시지가 출력됨
  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

 

4. CNI 설치

아래 명령어로 weave network add-on을 설치합니다.

<weabenet 설치>

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

## 실행결과
serviceaccount/weave-net created
clusterrole.rbac.authorization.k8s.io/weave-net created
clusterrolebinding.rbac.authorization.k8s.io/weave-net created
role.rbac.authorization.k8s.io/weave-net created
rolebinding.rbac.authorization.k8s.io/weave-net created
daemonset.apps/weave-net created

2022.10.20 일 기준으로 kubectl 버전에 따라 위의 명령어가 수행되지 않을 경우, 아래 명령어를 수행한다

kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

<calico 설치>

1. operator 설치

kubectl apply -f https://github.com/coreos/flannel/raw/master/Documentation/kube-flannel.yml

2. calico 설정 파일 다운로드

curl https://raw.githubusercontent.com/projectcalico/calico/v3.24.3/manifests/custom-resources.yaml -O

3. calico 설치

kubectl create -f custom-resources.yaml

 

<flannel 설치>

주의할 점 : master node에서 컨트롤 플레인 설정 시 반드시 --pod-network-cidr=10.244.0.0/16 옵션으로 수행해야 한다

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

아래 명령어로 flannel CNS를 설치한다.

kubectl apply -f https://github.com/coreos/flannel/raw/master/Documentation/kube-flannel.yml

 

 

5. node join

worker node에서 kubeadm join 수행

kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

 

6. 클러스터 설치 확인

$ kubectl get nodes

NAME       STATUS   ROLES           AGE   VERSION
master     Ready    control-plane   10h   v1.25.3
worker-1   Ready    <none>          10h   v1.25.3
worker-2   Ready    <none>          10h   v1.25.3

 

🔒  node join 추가하기

🔑 : kubernetes.io 사이트에서 busybox 로 검색 한 후 설정

1. container runtime 설치

$ apt install containerd

2. kubeadm, kubectl, kubelet 설치

추가할 node에 kubernetes.io 의 문서를 참조하여 설치

 

3. kubeadm create -- 명령어로 join 명령어 추출

$ kubeadm token create --print-join-command

## 아래 IP는 각자의 master node ip
kubeadm join 10.178.0.29:6443 --token i9ty38.mujkeddsah1364iu --discovery-token-ca-cert-hash sha256:a172d4a560907269b1b6cc6f40bc1e16fa8092831f92b24515297eb7b5a50a51

4. node join 수행

kubeadm create 명령어로 추출한 명령어를 master node에서 수행

kubeadm join 10.178.0.29:6443 --token i9ty38.mujkeddsah1364iu --discovery-token-ca-cert-hash sha256:a172d4a560907269b1b6cc6f40bc1e16fa8092831f92b24515297eb7b5a50a51

5. node 확인

kubectl get nodes 로 추가된 node 확인

 

🔒  POD 생성하기(Busybox sleep 3600)

🔑 : kubernetes.io 사이트에서 busybox 로 검색 한 후 설정

아래 내용의 busybox.yaml 파일로 pod를 생성한다.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'sleep 3600']

또는 아래 명령어를 수행한다.

kubectl run busybox --image=busybox --command -- sleep 3600

🔒  ETCD backup & restore

- etcdctl 설치

sudo apt install etcd-client

- etcd backup : etcd 프로세스를 grep 하면 프로세스에서 --trusted-ca-file, --cert-file, --key-file 옵션을 확인할 수 있다. 

각각 --cacert, --cert, --key 와 매칭된다. 마지막 snapshotdb는 백업파일명이다.

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
 --cert=/etc/kubernetes/pki/etcd/server.crt \
 --key=/etc/kubernetes/pki/etcd/server.key \
 snapshot save snapshotdb

Snapshot saved at snapshotdb

-etcd restore

ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb

OR

ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshotdb

db를 restore 한 후 static pod 인 etcd 에 정보를 수정한다. static pod 의 yaml 파일은 /etc/kubernetes/manifests 디렉토리에 etcd.yaml 파일로 존재한다. 복구한 디렉토리 정보를 이 파일을 수정해 준다. 수정할 곳은 2군데이다.

복원된 etcd 정보는 etcd pod가 자동으로 적용된다. 복구되는 동안에는 kubectl 명령어가 hang 상태가 된다.

(복구하는데 시간이 약간 소요된다)

spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=https://10.10.1.23:2379
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --client-cert-auth=true
    - --data-dir=/var/lib/etcd ==> 복원한 디렉토리로 수정
    
    volumeMounts:
    - mountPath: /var/lib/etcd ==> 복원한 디렉토리로 수정
      name: etcd-data
    - mountPath: /etc/kubernetes/pki/etcd
      name: etcd-certs

 

 

 

🔒  kubernetes Upgrade

업그레이드할 버전 결정

apt update
apt-cache madison kubeadm
# 목록에서 최신 버전(1.24)을 찾는다
# 1.24.x-00과 같아야 한다. 여기서 x는 최신 패치이다.

컨트롤 플레인 노드 업그레이드

컨트롤 플레인 노드의 업그레이드 절차는 한 번에 한 노드씩 실행해야 한다. 먼저 업그레이드할 컨트롤 플레인 노드를 선택한다. /etc/kubernetes/admin.conf 파일이 있어야 한다.

"kubeadm upgrade" 호출

첫 번째 컨트롤 플레인 노드의 경우

kubeadm 업그레이드 : x 문자를 업그레이드하려는 버전의 문자로 바꾼다.

# 1.24.x-00에서 x를 최신 패치 버전으로 바꾼다.
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.24.x-00 && \
apt-mark hold kubeadm

다운로드하려는 버전이 잘 받아졌는지 확인한다.

kubeadm version

업그레이드 계획을 확인한다.이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다. 또한 컴포넌트 구성 버전 상태가 있는 표를 보여준다.

kubeadm upgrade plan

 

업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다.

# 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
sudo kubeadm upgrade apply v1.24.x

 

명령이 완료되면 다음을 확인해야 한다.

[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.24.x". Enjoy! 
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.

 

CNI 제공자 플러그인을 수동으로 업그레이드한다.

 

다른 컨트롤 플레인 노드의 경우

첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다.

sudo kubeadm upgrade node

 

kubeadm upgrade plan 을 호출하고 CNI 공급자 플러그인을 업그레이드할 필요가 없다

노드 드레인

  • 예약 불가능으로 표시하고 워크로드를 제거하여 유지 관리를 위해 노드를 준비합니다.
  • # <node-to-drain>을 드레인하는 노드의 이름으로 바꾼다.
    kubectl drain <node-to-drain> --ignore-daemonsets

kubelet과 kubectl 업그레이드

  • 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다.
# replace x in 1.24.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.24.x-00 kubectl=1.24.x-00 && \
apt-mark hold kubelet kubectl
  • kubelet을 다시 시작한다.
sudo systemctl daemon-reload
sudo systemctl restart kubelet

노드 uncordon

  • 노드를 스케줄 가능으로 표시하여 노드를 다시 온라인 상태로 전환한다.
  • # <node-to-drain>을 드레인하는 노드의 이름으로 바꾼다.
    kubectl uncordon <node-to-drain>

워커 노드 업그레이드

워커 노드의 업그레이드 절차는 워크로드를 실행하는 데 필요한 최소 용량을 보장하면서, 한 번에 하나의 노드 또는 한 번에 몇 개의 노드로 실행해야 한다.

kubeadm 업그레이드

  • 모든 워커 노드에서 kubeadm을 업그레이드한다.
# 1.24.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubeadm && \
apt-get update && apt-get install -y kubeadm=1.24.x-00 && \
apt-mark hold kubeadm

"kubeadm upgrade" 호출

  • 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.
  • sudo kubeadm upgrade node
    

노드 드레인(master node에서 수행)

  • 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다.
  • # <node-to-drain>을 드레이닝하려는 노드 이름으로 바꾼다.
    kubectl drain <node-to-drain> --ignore-daemonsets
    

kubelet과 kubectl 업그레이드

  • kubelet 및 kubectl을 업그레이드한다.
# 1.24.x-00의 x를 최신 패치 버전으로 바꾼다
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet=1.24.x-00 kubectl=1.24.x-00 && \
apt-mark hold kubelet kubectl
  • kubelet을 다시 시작한다.
sudo systemctl daemon-reload
sudo systemctl restart kubelet

노드에 적용된 cordon 해제(master node에서 수행)

  • 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다.
  • # <node-to-drain>을 노드의 이름으로 바꾼다.
    kubectl uncordon <node-to-drain>

클러스터 상태 확인

모든 노드에서 kubelet을 업그레이드한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여 모든 노드를 다시 사용할 수 있는지 확인한다.

kubectl get nodes

모든 노드에 대해 STATUS 열에 Ready 가 표시되어야 하고, 버전 번호가 업데이트되어 있어야 한다

 

🔒  json format 출력

🔑 : jsonpath 형식으로 출력

 

 

🔒  디플로이먼트 업데이트

 

🔑 : 다음 단계에 따라 디플로이먼트를 업데이트한다.

nginx:1.14.2 이미지 대신 nginx:1.16.1 이미지를 사용하도록 nginx 파드를 업데이트 한다.

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

 

또는 다음의 명령어를 사용한다.

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

 

 

대안으로 디플로이먼트를 edit 해서 .spec.template.spec.containers[0].image 를 nginx:1.14.2 에서 nginx:1.16.1 로 변경한다.

kubectl edit deployment/nginx-deployment

다음과 유사하게 출력된다.

deployment.apps/nginx-deployment edited

롤아웃 상태를 보려면 다음을 실행한다

kubectl rollout status deployment/nginx-deployment

 

 

업데이트된 디플로이먼트에 대해 자세한 정보 보기

  • 롤아웃이 성공하면 kubectl get deployments 를 실행해서 디플로이먼트를 볼 수 있다. 이와 유사하게 출력된다.
  • NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           36s

kubectl get rs 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, 새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다.

kubectl get rs

 

이와 유사하게 출력된다.

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         3       6s
nginx-deployment-2035384211   0         0         0       36s

 

 

 

 

🔒  trouble shooting

 - kubelet, controller-manager, apiserver 등등 상태 분석

 - node 에 대해 describe, log 분석

 - pod에 대해 describe, log 분석

 - kubelet, controller-manager, apiserver 등등 상태 분석

  - 

 

🔒  kubernetes cluster 구성(with kubeadm 으로 설치)

- docker는 설치되어 있으니까, control plane에서 kubeadm(kubelet 이 같이 설치됨), CNI를 설치하고 worker node에서 kubeadm(kubelet 이 같이 설치됨)을 설치한 후 master node에 join 한다.

kubernetes 문서에서는 다 설치하는 것으로 설명되어 있으니 전체를 설치한다.

 

1) 6443 port가 사용하지 않고 있는지 확인(6443 port는 apiserver에서 사용할 port)

 - telnet 이나 nc 명령어로 확인

nc 127.0.0.1 6443

 

2) kubeadm, kubelet and kubectl 설치

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

3) control-plane node 초기화

kubeadm init

4) 환경 설정

일반 user로 kubectl 명령어를 사용하기 위해 아래 명령어를 수행

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

root 는 아래 명령어 수행

echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bashrc

 

5) CNI 설치

공식문서에서 CNI 설치 명령어를 찾을 수 없음.

how ? 별도 url 에서 찾는다. <<< 문서를 찾는 단어를 찾아본다 >> v1-2... 이런게 있었던거 같다.

 CNI 설치(flannel or weave-net)

 

 

🔒 참고

 

pod spec의 arg와 command 차이

command는 docker 의 ENTRYPOINT이고 arg는 CMD이다.

 

'쿠버네티스' 카테고리의 다른 글

쿠버네티스 - play with k8s  (0) 2022.10.20
쿠버네티스 설치 - unbutu 22.04  (0) 2022.06.27
쿠버네티스 보충  (0) 2022.06.08
CKA 자격증 취득하기 #2  (0) 2022.05.23
CKA 자격증 취득하기 #1  (0) 2022.05.18

 

왜 ingress를 써야 하나?

 

service는 서비스당 하나의 port 만을 open할 수 있기 때문에 서비스가 많아진다.

반면, 인그레스는 포트는 하나만 open하고 도메인이나 path로 서비스를 분기해 줄 수 있기 때문이다.

 

sslip.ip는 임시로 도메인을 생성해 준다.

ingress 테스트시 사용할 수 있다.

 

 

Kubectl 자동 완성

BASH

source <(kubectl completion bash) # bash-completion 패키지를 먼저 설치한 후, bash의 자동 완성을 현재 셸에 설정한다
echo "source <(kubectl completion bash)" >> ~/.bashrc # 자동 완성을 bash 셸에 영구적으로 추가한다

또한, kubectl의 의미로 사용되는 약칭을 사용할 수 있다.

alias k=kubectl
complete -F __start_kubectl k

자동완성 기능이 활성화되지 않을 경우 bash_completion 이 설치되어 있는지 확인하여, 설치가 되어 있지 않을 경우 설치해 준다.

apt-get install bash_completion

 

kubetl 명령어 뒤에 올 수 있는 type이나 

kubectl completion bash > /etc/bash_completion.d/kubectl

 

kubectx, kubens 는?

kubectx란?

  • 다중클러스터 사용시 클러스터 전환을 쉽게 해주는 플러그인 툴

kubens란?

  • k8s cluster 내에 namespace를 쉽게 전환해주는 플러그인 툴

kubetail

pod 의 로그를 확인

 

 

ETCD 데이터 조회


ETCDCTL_API=3 etcdctl --endpoints=https://[10.10.1.23]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key get --prefix=true "" > /tmp/prefix

cat /tmp/prefix | nl | tail 
cat /tmp/prefix | nl | grep -i 'pod":"busybox-sleep-less'

 

 

'쿠버네티스' 카테고리의 다른 글

쿠버네티스 설치 - unbutu 22.04  (0) 2022.06.27
CKA 자격증 취득하기 - 시험예상 문제  (0) 2022.06.09
CKA 자격증 취득하기 #2  (0) 2022.05.23
CKA 자격증 취득하기 #1  (0) 2022.05.18
쿠버네티스 - secret  (0) 2022.05.18

본 문서에서는 debian OS를 기준으로 설치를 설명합니다.

설치환경

- OS : ebian GNU/Linux 11 (bullseye)

- 자원

  • 2 CPUs or more
  • 2GB of free memory
  • 20GB of free disk space

minikube 란

Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구입니다. Minikube는 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 가상 머신(VM) 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행합니다

쿠버네티스 클러스터를 구축하는 방법에는 kubernetes, minikube, kind, k3s 등 여러가지가 있습니다.

 

설치 전 준비사항

  • Docker 설치 - minikube를 사용하기 위한 환경으로 minikube 설치 전에 Docker를 설치합니다.
  • kubectl 설치 - kubectl은 kubernetes의 cluster와 통신하여 다양한 object들의 상태확인 또는  생성.삭제 작업 등을 위해 사용되는 CLI 도구입니다. minikube 설치 후 설치해줍니다.

 

1. docker 설치 

 

도커 GPG 키 추가

$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

 

repository 설정

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Docker Engine 설치

아래 명령어로 도커 엔진을 설치합니다.

 $ sudo apt-get update
 $ sudo apt-get install docker-ce docker-ce-cli containerd.io

 

도커 설치가 완료되면 일반 유저도 사용할 수 있도록 docker 실행 권한을 줍니다.

sudo usermod -aG docker $USER && newgrp docker

2. minikube 설치

우분투 환경(debian, ubuntu 계열)에서 minikube를 설치하는 명령어입니다. 다른 환경에서 설치하는 명령은 https://minikube.sigs.k8s.io/docs/start 를 참고하면 됩니다. 아래는 debina pakcage로 설치하는 방법과 binary file로 설치하는 방법입니다. 2개의 방법 중 원하는 방식으로 설치하면 됩니다.

1) Debian package로 설치
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
sudo dpkg -i minikube_latest_amd64.deb

2) binary file로 설치

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

 

 minikube 클러스터 실행

minikube start 명령으로 minikube 클러스터를 실행합니다.

minikube start

minikube 상태 확인

$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

minikube 클러스터 접속

minikube ssh

기타 명령어

minikube ip : 클러스터 IP

minikube stop :클러스터 중지

minikube delete : 클러스터 삭제

 3. kubectl 설치

 apt 패키지 색인을 업데이트하고 쿠버네티스 apt 리포지터리를 사용하는 데 필요한 패키지들을 설치한다.

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

구글 클라우드 공개 사이닝 키를 다운로드한다.

sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

쿠버네티스 apt 리포지터리를 추가한다.

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

새 리포지터리의 apt 패키지 색인을 업데이트하고 kubectl을 설치한다.

sudo apt-get update
sudo apt-get install -y kubectl

클러스터 상태를 가져와서 kubectl이 올바르게 구성되어 있는지 확인합니다.

kubectl cluster-info

 

3minikube cluster 확인

kubectl이 이미 설치되어 있다면 이제 이를 사용하여 클러스터에 액세스할 수 있습니다.

kubectl get po -A
 

또는 minikube에서 적절한 버전의 kubectl을 다운로드할 수 있으며 다음과 같이 사용할 수 있습니다.

minikube kubectl -- get po -A
 

You can also make your life easier by adding the following to your shell config:

alias kubectl="minikube kubectl --"
 

Initially, some services such as the storage-provisioner, may not yet be in a Running state. This is a normal condition during cluster bring-up, and will resolve itself momentarily. For additional insight into your cluster state, minikube bundles the Kubernetes Dashboard, allowing you to get easily acclimated to your new environment:

클러스터 상태에 대한 정보를 확인하기 위해 minikube는 Kubernetes 대시보드를 번들로 제공합니다.

minikube dashboard

 

 

 

 

Set up the repository

  1. Update the apt package index and install packages to allow apt to use a repository over HTTPS:
  2. $ sudo apt-get update
    
    $ sudo apt-get install \
        ca-certificates \
        curl \
        gnupg \
        lsb-release
  3. Add Docker’s official GPG key:
  4. $ sudo mkdir -p /etc/apt/keyrings
    $ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
  5. Use the following command to set up the repository:
  6. $ echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
      $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install Docker Engine

This procedure works for Debian on x86_64 / amd64, armhf, arm64, and Raspbian.

  1. Update the apt package index, and install the latest version of Docker Engine, containerd, and Docker Compose, or go to the next step to install a specific version:
  2.  
  3.  $ sudo apt-get update
     $ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
  1. To install a specific version of Docker Engine, list the available versions in the repo, then select and install:
    $ apt-cache madison docker-ce
    
      docker-ce | 5:18.09.1~3-0~debian-stretch | https://download.docker.com/linux/debian stretch/stable amd64 Packages
      docker-ce | 5:18.09.0~3-0~debian-stretch | https://download.docker.com/linux/debian stretch/stable amd64 Packages
      docker-ce | 18.06.1~ce~3-0~debian        | https://download.docker.com/linux/debian stretch/stable amd64 Packages
      docker-ce | 18.06.0~ce~3-0~debian        | https://download.docker.com/linux/debian stretch/stable amd64 Packages
    
    b. Install a specific version using the version string from the second column, for example, 5:18.09.1~3-0~debian-stretch .
  2. $ sudo apt-get install docker-ce=<VERSION_STRING> docker-ce-cli=<VERSION_STRING> containerd.io docker-compose-plugin
    
  3. a. List the versions available in your repo:
  4. Verify that Docker Engine is installed correctly by running the hello-world image.This command downloads a test imag
  5. $ sudo docker run hello-world
    

 

To create the docker group and add your user:

  1. Create the docker group.
  2. $ sudo groupadd docker
  3. Add your user to the docker group.
  4. $ sudo usermod -aG docker $USER
  5. Log out and log back in so that your group membership is re-evaluated.On a desktop Linux environment such as X Windows, log out of your session completely and then log back in.
    $ newgrp docker 
    
  6. On Linux, you can also run the following command to activate the changes to groups:
  7. If testing on a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.
  8. Verify that you can run docker commands without sudo.This command downloads a test image and runs it in a container. When the container runs, it prints a message and exits.
    WARNING: Error loading config file: /home/user/.docker/config.json -
    stat /home/user/.docker/config.json: permission denied
    
    To fix this problem, either remove the ~/.docker/ directory (it is recreated automatically, but any custom settings are lost), or change its ownership and permissions using the following commands:
  9. $ sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
    $ sudo chmod g+rwx "$HOME/.docker" -R
    
  10. If you initially ran Docker CLI commands using sudo before adding your user to the docker group, you may see the following error, which indicates that your ~/.docker/ directory was created with incorrect permissions due to the sudo commands.
  11. $ docker run hello-world
    

Configure Docker to start on boot

Most current Linux distributions (RHEL, CentOS, Fedora, Debian, Ubuntu 16.04 and higher) use systemd to manage which services start when the system boots. On Debian and Ubuntu, the Docker service is configured to start on boot by default. To automatically start Docker and Containerd on boot for other distros, use the commands below:

$ sudo systemctl enable docker.service
$ sudo systemctl enable containerd.service

To disable this behavior, use disable instead.

$ sudo systemctl disable docker.service
$ sudo systemctl disable containerd.service

If you need to add an HTTP Proxy, set a different directory or partition for the Docker runtime files, or make other customizations, see customize your systemd Docker daemon options.

'Docker' 카테고리의 다른 글

도커 - web was 구성  (0) 2022.04.21
Docker Compose 네트워크  (0) 2022.04.21
Docker - 네트워크  (0) 2022.04.21
Docker - 파일 저장 위치  (0) 2022.04.19
Install Docker Engine on CentOS  (0) 2022.04.18

+ Recent posts