Apache Mesos vs Kubernetes

주의할 점은 Kubernetes를 Mesos와 직접 비교하는 것은 완전히 공정하지 않다는 것입니다. 우리가 추구하는 대부분의 컨테이너 오케스트레이션 기능은 Marathon과 같은 Mesos 프레임워크 중 하나에서 제공됩니다. 따라서 올바른 관점에서 상황을 유지하기 위해 Kubernetes를 직접 Mesos가 아닌 Marathon과 비교하려고 합니다.

이러한 시스템의 원하는 속성 중 일부를 기반으로 이러한 오케스트레이션 시스템을 비교할 것입니다.

지원되는 워크로드

Mesos는 컨테이너화되거나 비컨테이너화될 수 있는 다양한 유형의 워크로드를 처리하도록 설계되었습니다. 우리가 사용하는 프레임워크에 따라 다릅니다. 우리가 보았듯이 Marathon과 같은 프레임워크를 사용하여 Mesos에서 컨테이너화된 워크로드를 지원하는 것은 매우 쉽습니다.

반면 Kubernetes는 컨테이너화된 워크로드에서만 작동합니다. 가장 광범위하게 Docker 컨테이너와 함께 사용하지만 Rkt와 같은 다른 컨테이너 런타임을 지원합니다. 앞으로 Kubernetes는 더 많은 유형의 워크로드를 지원할 수 있습니다.

확장성(Scalability) 지원

Marathon은 애플리케이션 정의 또는 사용자 인터페이스를 통한 확장을 지원합니다. Autoscaling은 Marathon에서도 지원됩니다. 또한 모든 종속성을 자동으로 확장하는 애플리케이션 그룹을 확장할 수 있습니다.

Pod는 Kubernetes의 기본 실행 단위입니다. Pod는 Deployment에서 관리할 때 확장할 수 있습니다. 이것이 Pod가 항상 배포로 정의되는 이유입니다. 스케일링은 수동 또는 자동일 수 있습니다.

고가용성(High Availability) 처리

Marathon의 애플리케이션 인스턴스는 고가용성을 제공하는 Mesos 에이전트에 분산됩니다. 일반적으로 Mesos 클러스터는 여러 에이전트로 구성됩니다. 또한 ZooKeeper는 쿼럼 및 리더 선택을 통해 Mesos 클러스터에 고가용성을 제공합니다.

마찬가지로 Kubernetes의 포드는 여러 노드에 복제되어 고가용성을 제공합니다. 일반적으로 Kubernetes 클러스터는 여러 작업자 노드로 구성됩니다. 또한 클러스터에는 여러 마스터가 있을 수도 있습니다. 따라서 Kubernetes 클러스터는 컨테이너에 고가용성을 제공할 수 있습니다.

서비스 검색 및 로드 밸런싱

Mesos-DNS는 애플리케이션에 대한 서비스 검색 및 기본 로드 밸런싱을 제공합니다. Mesos-DNS는 각 Mesos 작업에 대한 SRV 레코드를 생성하고 작업을 실행하는 시스템의 IP 주소 및 포트로 변환합니다. Marathon 애플리케이션의 경우 Marathon-lb를 사용하여 HAProxy를 사용하여 포트 기반 검색을 제공할 수도 있습니다.

Kubernetes에 배포하면 포드가 동적으로 생성 및 소멸됩니다. 따라서 일반적으로 서비스 검색을 제공하는 Service를 통해 Kubernetes에서 Pod를 노출합니다. Kubernetes의 서비스는 포드에 대한 디스패처 역할을 하므로 로드 밸런싱도 제공합니다.

업그레이드 및 롤백 수행

Marathon에서 애플리케이션 정의에 대한 변경 사항은 배포로 처리됩니다. 배포는 애플리케이션의 시작, 중지, 업그레이드 또는 확장을 지원합니다. Marathon은 또한 최신 버전의 애플리케이션을 배포하기 위한 롤링 시작(Rolling Start)을 지원합니다. 그러나 롤백은 간단하며 일반적으로 업데이트된 정의를 배포해야 합니다.

Kubernetes의 배포는 업그레이드 및 롤백을 지원합니다. 우리는 이전 포드를 새 포드로 교체하면서 취할 배포 전략을 제공할 수 있습니다. 일반적인 전략은 재생성 또는 롤링 업데이트입니다. 배포의 롤아웃 기록은 기본적으로 Kubernetes에서 유지 관리되므로 이전 버전으로 쉽게 롤백할 수 있습니다.

로깅 및 모니터링

Mesos에는 모든 클러스터 구성 요소를 스캔하고 상태 및 기타 Metric과 관련된 데이터를 사용할 수 있도록 하는 진단 유틸리티가 있습니다. 사용 가능한 API를 통해 데이터를 쿼리하고 집계할 수 있습니다. 이 데이터의 대부분은 Prometheus와 같은 외부 도구를 사용하여 수집할 수 있습니다.

Kubernetes는 리소스 Metric 또는 전체 Metric 파이프라인으로 다른 개체와 관련된 자세한 정보를 제공합니다. 일반적인 방법은 Kubernetes 클러스터에 ELK 또는 Prometheus+Grafana와 같은 외부 도구를 배포하는 것입니다. 이러한 도구는 클러스터 Metric을 수집하고 훨씬 사용자 친화적인 방식으로 제공할 수 있습니다.

저장소(Storage)

Mesos에는 상태 저장 애플리케이션을 위한 영구 로컬 볼륨이 있습니다. 예약된 리소스에서만 영구 볼륨을 생성할 수 있습니다. 일부 제한 사항이 있는 외부 저장소도 지원할 수 있습니다. Mesos는 스토리지 공급업체와 컨테이너 오케스트레이션 플랫폼 간의 공통 API 세트인 CSI(Container Storage Interface)에 대한 실험적인 지원을 제공합니다.

Kubernetes는 상태 저장 컨테이너에 대해 여러 유형의 영구 볼륨을 제공합니다. 여기에는 iSCSI, NFS와 같은 스토리지가 포함됩니다. 또한 AWS, GCP와 같은 외부 스토리지도 지원합니다. Kubernetes의 Volume 객체는 이 개념을 지원하며 CSI를 비롯한 다양한 유형으로 제공됩니다.

네트워킹

Mesos의 컨테이너 런타임은 두 가지 유형의 네트워킹 지원, 컨테이너당 IP 및 네트워크 포트 매핑을 제공합니다. Mesos는 컨테이너에 대한 네트워킹 정보를 지정하고 검색하기 위한 공통 인터페이스를 정의합니다. Marathon 애플리케이션은 호스트 모드 또는 브리지 모드에서 네트워크를 정의할 수 있습니다.

Kubernetes의 네트워킹은 각 포드에 고유한 IP를 할당합니다. 이렇게 하면 컨테이너 포트를 호스트 포트에 매핑할 필요가 없습니다. 또한 이러한 포드가 노드 간에 서로 통신할 수 있는 방법을 정의합니다. 이것은 Cilium, Contiv와 같은 네트워크 플러그인에 의해 Kubernetes에서 구현됩니다.

무엇을 사용할까?

명확한 결과를 기대하지만, 어떤 기술이 다른 기술보다 우수하다고 선언하는 것은 전적으로 공정하지 않습니다. 우리가 보았듯이 Kubernetes와 Mesos는 모두 강력한 시스템이며 상당히 경쟁적인 기능을 제공합니다.

그러나 성능은 상당히 중요한 측면입니다. Kubernetes 클러스터는 5000개 노드로 확장할 수 있으며 Marathon on Mesos 클러스터는 최대 10,000개의 에이전트를 지원하는 것으로 알려져 있습니다. 대부분의 실제 사례에서 우리는 그러한 큰 클러스터를 다루지 않을 것입니다.

마지막으로 유연성과 워크로드 유형으로 귀결됩니다. 새로 시작하고 컨테이너화된 워크로드만 사용할 계획이라면 Kubernetes가 더 빠른 솔루션을 제공할 수 있습니다. 그러나 컨테이너와 비컨테이너가 혼합된 기존 워크로드가 있는 경우 Mesos with Marathon이 더 나은 선택이 될 수 있습니다.

다른 대안

Kubernetes와 Apache Mesos는 꽤 강력하지만, 이 공간에서 유일한 시스템은 아닙니다. 우리가 이용할 수 있는 유망한 대안들이 꽤 많이 있습니다.. 자세한 내용은 다루지 않겠지만 몇 가지 항목을 간단히 나열해 보겠습니다.

  • Docker Swarm: 도커 스웜은 도커 컨테이너를 위한 오픈 소스 클러스터링 및 스케줄링 도구이다. Docker 호스트의 클러스터를 관리하는 명령줄 유틸리티가 제공됩니다. Kubernetes나 메소스와 달리 도커 컨테이너에 한정되어 있습니다.
  • Nomad: Nomad는 HashiCorp의 유연한 워크로드 조정자로 컨테이너형 또는 컨테이너형이 아닌 애플리케이션을 관리합니다. Nomad는 Docker 컨테이너와 같은 애플리케이션을 배포하기 위한 선언적 인프라(Infrastructure-as-code)를 활성화합니다.
  • OpenShift: 오픈시프트는 레드햇의 컨테이너 플랫폼으로, 쿠버네티스가 주관하고 관리합니다. OpenShift는 Kubernetes가 제공하는 통합 이미지 레지스트리, 소스-이미지 빌드, 네이티브 네트워킹 솔루션과 같은 많은 기능을 제공합니다.
반응형

 

Error

Failed to get D-Bus connection: Operation not permitted

docker 는 기본적으로 컨테이너는 다중 프로세스를 실행하도록 설계되지 않았으므로 기본적으로 systemd를 실행하지 않습니다.

# docker exec -it {CONTAINER ID} /bin/bash

를 통해서 접속을 해서 이것저것 실행하다가, systemctl 명령어로 서비스 올라와 있는 것을 restart 와 같은 명령어를 실행하려고 할때 나타난다.

httpd 또는 nginx 와 같은 서비스를 실행하거나 재실행, 끄기 위해서는 직접 실행 명령어를 입력하면 된다.

예를 들어서

# /usr/sbin/nginx -s stop 

과 같은 명령어를 Reference와 같이 찾아서 사용하면 된다.

반응형

'개발 > 가상화' 카테고리의 다른 글

kubernetes_gcloud_1_docker_introduce  (0) 2023.04.18
Apache Mesos, Kubernetes 비교  (0) 2022.09.15
kubernetes | 우분투 kubernetes 설치  (0) 2022.07.06
kubenetes | vagrant 로 구성하기  (0) 2022.07.06
kubernetes | command  (0) 2022.07.05

Imgur

Ansible

Ansible은 오픈 소스 소프트웨어 프로비저닝, 구성 관리, 애플리케이션 전개 도구이다. 수많은 유닉스 계열 시스템에서 실행되며 유닉스 계열 운영 체제 및 마이크로소프트 윈도우의 구성이 가능하다.
시스템 구성을 기술하기 위해 자체 선언형 언어를 포함하고 있다. 위키백과

  • 테스트 환경을 구축(다양한 OS)

  • python으로 개발 되었고 YAML 언어를 통해 정의할 수 있고, JSON 방식으로 통신

  • OPEN Source

기본개념

환경설정, 배포를 가능케 하는 언어. 리모트 서버에 접속해서 무언가를 실행시키는 정책을 기술한다. YAML 문법으로 정책이 기술되어 고급 단계에서 로드밸런서를 모니터링하는 복잡한 환경에서도 사용할 수 있도록 한다.

playbook은 하나 또는 하나 이상의 play를 두게 되고, play의 목적은 여러 호스트들을 잘 정의 된 ROLETASK를 매핑하는 역할을 합니다. TASKAnsible모듈의 호출을 의미한다.
ROLE을 더 편하게 관리하기 위해서 YAML파일로 정의해서 사용할 수 있다. 또한 host inventory 파일에 정의한 서버 그룹별로 각각 나누너 provision 할 수 있도록 할 수 있다.

장점

  • 빠른 SSH 통신, 빠른 Provision을 이용가능

  • agent daemon을 사용하지 않음

  • 자동 배포 환경이 구성 쉬움

  • 멱등성
    여러 번 적용해도 결과 변동 없음
    바뀌는 것이 없으면 당연히 배포되어도 변경 없음
    바뀌는 부분이 있으면 그 부분만 반영
    shell, command, file module은 보장 안됨

  • playbook

  • ad-hoc 지원

  • 병렬 Provisioning 지원

단점

  • 시스템 초기 설치 수행은 불가능

  • 시스템 모니터링은 지원 안함

  • 시스템 변경사항 초적하지 않음

할수있는 것

앤서블에는 크게 3가지 요소가 있다.
inventory, playbook, module이 그것이다.
이는 각각 (1) 어디서, (2) 무엇을, (3) 어떻게 수행할지를 정의한다. (엄밀히 말하면 모듈이 플레이북에서 사용되지만, 이해를 위해 구분해 설명한다)

inventory

remote server에 대한 meta 데이터를 기술하는 파일.
인벤터리는 앤서블에 의해 제어되어 Infrastructure as a Code의 대상이 될 서버들의 목록을 정의하는 파일 일반적으로 hosts.ini 파일에 정의해 사용하는 듯 하며, 위 예시에서 작성했던 hosts.ini 파일이 바로 그것이다.
인벤터리에는 여러 서버들의 접속 정보 (SSH 접근 IP, 포트, 리눅스 사용자) 등을 정의.
기본 파일은 /etc/ansible/hosts를 읽게 하거나, 따로 inventory파일을 만들고 옵션을 주어 동작하게 할 수 있다. 만약 고정 ip를 가지고 있고, ghost 파일 안에 들어가 있지 않는 서버가 있다면 설정 파일을 만들 수 있고 테스트 환경을 만들 때 유용하다.

대충 아래와 같은 파일로 구성이 된다.

centos1 ansible_host=172.16.49.133 ansible_user=root
centos2 ansible_host=172.16.49.134 ansible_user=root
zabbix ansible_host=172.16.49.135 ansible_user=root

[server]
centos1
centos2
zabbix

PLAYBOOK

설정을 관리가호 다수의 머신에 대한 배포 시스템에 대한 기본적인 단위. 복잡한 형태의 배포에 매우 적합하다. 설정을 정의할 수 있으며 특정머신의 집합을 오가며 다른 작업을 수행하도록 수동으로 작업 순서를 설정하는 것도 가능하다. 이 때의 작업은 동기 또는 비동기로 수행할 수 이다. /usr/bin/ansible명령을 통해서 AD-HOC 테스크를 실행하는 것에 반해 PLAYBOOK은 소스 컨트롤을 통해 보관하거나 사용자의 설정을 내보내거나 원격 시스템을 구성,보장디는데 더욱 적합합니다.

Module

이미 정의해 놓은 모듈들을 통해서 다중명령어를 보내줄 수 있다. 예를 들어 yum이라는 모듈을 통해서 설치작업을 요청할 수 있으며, shell모듈을 통해서 커맨드 입력을 보낼 수 있다.

ansible -l #모든 module 목록 조회

ad-hoc

adhoc이라는 의미는 임시적 수행을 말한다.
ansible의 playbook을 작성하는 것이 아니라 임시적으로 또는 특별하게 어떤 작업을 수행하기 위해서 사용할 수 있는 실행방법이라고 할 수 있다.

Ansible 시작하기

![](/Users/forteleaf/Library/Application Support/marktext/images/2019-09-06-16-16-11-image.png)

기본옵션 (Inventory)

hosts.ini파일을 아래와 같이 설정 된다. 파일 이름은 정해진 틀이 없으므로 편한데로 맞춰서 사용합니다.

centos1 ansible_host=172.16.49.133 ansible_user=root
centos2 ansible_host=172.16.49.134 ansible_user=root
zabbix ansible_host=172.16.49.135 ansible_user=root

[server]
centos1
centos2
zabbix

ssh-copy-id로 자동로그인을 설정해 놓으면 ansible_password와 같은 옵션을 따로 설정하지 않아도 된다.

설정파일 ( ansible.cfg / .ansible.cfg )

ansible.cfg파일을 지정해 줌으로서 옵션에 넣을 변수를 줄이고 편하게 사용할 수 있다

## ansible.cfg
[defaults]
inventofy=./hosts.ini
remote_user=root
private_key_file=~/.ssh/id_rsa

host_key_checking=false옵션을 추가하면, 접속시 key 확인하는 작업을 스킵합니다. 일일히 yes칠 상황을 제거해 줍니다

service 상태 조회

ansible all -m shell -a "service status sshd"

모듈 ( MODULE )

모듈들은 정말 다양한 기능들을 제공한다. 이런 기능은 없나? 생각하면 이미 개발되어 있는 상황이고 그게 안된다면, shell또는 command명령을 통해서 작업할 수 있다

shellcommand 모듈의 차이

Module : command

원격 노드에서 명령을 실행

명령 모듈은 명령 이름 뒤에 공백으로 구분 된 인수 목록을 사용합니다. 주어진 명령은 선택된 모든 노드에서 실행됩니다.
쉘을 통해 처리되지 않으므로 $HOME과 같은 변수 및 "<", ">", "|"및 "&"와 같은 조작은 작동하지 않습니다 (이 기능이 필요한 경우 쉘 모듈을 사용하십시오).

Module : shell

노드에서 명령을 실행

쉘 모듈은 명령 이름 뒤에 공백으로 구분 된 인수 목록을 사용합니다. 명령 모듈과 거의 동일하지만 원격 노드의 쉘 (/bin/sh)을 통해 명령을 실행합니다.

Module : template

nginx.ini와 같은 설정 파일을 role을 지정해서 서버마다 다른 설정 값을 넣어서 파일을 생성할 수 있는 기능입니다. 자주 사용되는 기능

PLAYBOOK

# public key 를 server들에 등록하는 playbook
---
- hosts: all    # inventory 의 모든 대상
  tasks:        # 수행할 작업
    - name: authorized to server    # 작업 이름
      authorized_key:               # 수행할 MODULE 명
        user: root                  # MODULE에 들어갈 environment
        state: present
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" 

yml(야믈)의 파일 구조를 갖고 있습니다. 규칙성에서 벗어나면 제대로 동작하지 않습니다. 이를 유의해 주시면서 작업 하시면 오히려 정규화 된 표현에 코드 리딩하기 편할 것 입니다.

authorized_key를 사용하기 위해서는 암호또한 자동으로 입력 해 주는 sshpass가 필요합니다.

유용한 유틸리티

문법체크

$ ansible-playbook --syntax-check [file]

호스트 나열

$ ansible-playbook --list-hosts [file]

테스크 나열

$ ansible-playbook --list-tasks[file]

#체크모드

$ ansible-playbook --check [file]

참조


반응형

본 글은 kubernetes | vagrant and docker 글에서 이어집니다.
https://docs.docker.com/engine/install/ubuntu/#set-up-the-repository 내용을 참고해서 설치합니다.

docker 설치

$ sudo apt-get update

$ sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

docker offical GPG key. 등록

$ sudo mkdir -p /etc/apt/keyrings

$ curl -fsSL https://download.docker.com/linux/ubuntu/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/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

docker-engine 설치

$ sudo apt-get update

$ sudo apt-get -y install docker-ce docker-ce-cli containerd.io docker-compose-plugin
$ sudo systemctl enable docker
$ sudo systemctl start docker

kubenetes 설치

사전준비 사항

  1. 환경설정
  2. kubeaadm, kubectl, kubelet 설치
  3. control-plane 구성
  4. worker node 구성
  5. 설치확인

1, swap 제거

스왑의 비활성화. kubelet이 제대로 작동하게 하려면 반드시 스왑을 사용하지 않도록 설정한다

$ swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab

2. iptables가 브리지된 트래픽을 보게 하기

Letting iptables see bridged traffic

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

$ cat <<EOF | tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

$ sudo sysctl --system

3. 방화벽 설정

앞단에 방화벽이 대부분 존재합니다. 방화벽을 끄고 사용하도록 합니다.

$ systemctl stop firewalld 
$ systemctl disable firewalld

selinux disabled 설정

4) Set SELinux in permissive mode (effectively disabling it)
# setenforce 0
# sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

kubeadm, kubelet, kubectl 설치


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

$ 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

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

3. Initializing your control-plane node

$ kubeadm init -- 옵션들
[init] Using Kubernetes version: v1.24.1
[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
        [ERROR CRI]: container runtime is not running: output: E0531 14:39:51.155826   27989 remote_runtime.go:925] "Status from runtime service failed" err="rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
time="2022-05-31T14:39:51Z" level=fatal msg="getting status of runtime: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
, error: exit status 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher

에러가 발생했습니다. 아래와 같이 설정파일 날리고 재실행하니 문제가 없었습니다.

unknown service runtime.v1alpha2.RuntimeService 과 같은 오류가 발생하게 되면 컨테이너 런타임에서 CRI 기능을 비활성화 한 경우이므로 다음 추가 작업을 진행합니다.
전체 master, node1, node2 에서

$ rm /etc/containerd/config.toml
# 아니면 안에 cri 내용을 주석처리 한다.
$ sudo systemctl restart containerd

가상환경에서는 --apiserver-advertise-address옵션을 줘야 192.168.56.xxx 으로 통신을 할 수 있습니다.

calico 기반

$ ubeadm init --apiserver-advertise-address=10.0.0.10 --pod-network-cidr=192.168.0.0/16

flannel 기반

(Master)$ sudo kubeadm init --apiserver-advertise-address=192.168.56.100 --pod-network-cidr=10.244.0.0/16

kubeadm를 초기화 한다. –pod-network-cidr는 반드시 10.244.0.0/16으로 설정해야 한다. Docker Version으로 인한 Error가 발생하면 kubeadm init 마지막에 '–ignore-preflight-errors=SystemVerification'를 붙인다.

아래와 같은 로그들이 출력 된다.

[init] Using Kubernetes version: v1.24.1
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master] and IPs [10.96.0.1 10.0.2.15]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost master] and IPs [10.0.2.15 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost master] and IPs [10.0.2.15 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 10.507423 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node master as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: 39tu9f.zvo7sn8r11613q4u
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

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

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.56.10:6443 --token 39tu9f.zvo7sn8r11613q4u \
        --discovery-token-ca-cert-hash sha256:a5ff918cb85ae91f474f8b49b7b3c2047c9eaa9be158c6cc470a382b7e3f9aee

controller, schedular, etcd 등이 생성된다.
node들에서 master와 연결을 하기 위해서는 token 정보를 알고 있어야 합니다.
아래는 예시입니다. 테스트기기 마다ㅏ 값이 다르기 때문에 메모할 필요가 있습니다

$ kubeadm join 192.168.56.10:6443 --token 39tu9f.zvo7sn8r11613q4u \
        --discovery-token-ca-cert-hash sha256:a5ff918cb85ae91f474f8b49b7b3c2047c9eaa9be158c6cc470a382b7e3f9aee

pod network

master에서만 실행

weave 계열

$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
ARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
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

flannel 설치

--pod-network-cidr=10.244.0.0/16 들 추가한다.

$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

vagrant network 에러

-- https://github.com/k3s-io/k3s/issues/72 에서 해결책을 찾음

$ wget https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
$ vi kube-flannel.yml
수정

  containers:
      - name: kube-flannel
        image: quay.io/coreos/flannel:v0.10.0-amd64
        command:
        - /opt/bin/flanneld
        args:
        - --ip-masq
        - --kube-subnet-mgr
        - --iface=enp0s8

자동완성 설정

# setup autocomplete in bash into the current shell, bash-completion package should be installed first.
$ source <(kubectl completion bash) 
# add autocomplete permanently to your bash shell.
$ echo "source <(kubectl completion bash)" >> ~/.bashrc
$ source ~/.bashrc

root 에서 안 error가 발생할 시 아래 내용을 /etc/bash.bashrc에 넣습니다. log out 후에 재접속 하면 반영 되는 것을 확인 할 수 있습니다.

echo 'if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi' >> /etc/bash.bashrc

master node에서도 pod이 생성 되게 설정

# kubectl taint nodes --all node-role.kubernetes.io/control-plane- node-role.kubernetes.io/master-

dashboard 설치

https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ 에 최신버전을 확인해nr 사용하도록 한다.

(Master)# kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml

localhost:8080 error

worker node에서는 에러가 난다.. 모든 설정은 node1에서 되고 있으니 문제가 없어영

유용한 참조 블로그

https://ssup2.github.io/record/Kubernetes_%EC%84%A4%EC%B9%98_kubeadm_Ubuntu_18.04/

  • CNI 네트워크 설정을 해결하는데 큰 도움이 됨
반응형

'개발 > 가상화' 카테고리의 다른 글

Apache Mesos, Kubernetes 비교  (0) 2022.09.15
docker | error : Failed to get D-Bus connection: Operation not permitted  (0) 2022.07.14
kubenetes | vagrant 로 구성하기  (0) 2022.07.06
kubernetes | command  (0) 2022.07.05
XCP-ng Tools 설치  (0) 2018.11.29

kubernetes 환경을 로컬에 구성하기 위해서 virtualbox + vagrant 조합으로 쿠버네티스 구성을 만들어 보려고 합니다. 개발환경은 맥을 사용하기 때문에 homebrew를 통해서 설치하려고 합니다.

virtualboxvagrant를 설치합니다.

vagrantvirtualbox 를 관리하고 설정을 스크립트로 저장해서 사용할 수 있게 해주는 툴입니다. 간단한 for반복문을 통해서 어려대의 서버를 한꺼번에 생성할 수 있습니다. (병렬 생성은 아니고, 한개씩한개씩 생성합니다.)

1. virtual machine 준비

1.1. virtualbox, vagrant 설치

$ brew install virtualbox vagrant

Vagrantdocker-compose와 같이 폴더 안에 vagrantfile 파일을 통해서 virtualBox를 제어합니다.

1.1. OS 준비

이번에는 우분투를 사용해서 구성해 보려고 합니다. 지속적으로 업데이트되고있는 ubuntu 이미지를 사용했습니다. (개인적으로 레드햇계열을 사용하는데, 이미지가 안보여서 Debian 계열로 설치해 봤습니다.)

https://app.vagrantup.com/ubuntu/boxes/focal64 에 들어가면 vagrantfile에 들어가는 설정을 확인할 수 있습니다.

1.1.1. vagrantfile 생성

vagrant init 명령어를 통해서 vagrantfile파일을 생성합니다.

$ vagrant init ubuntu/focal64
$ vagrant up

아래는 vmware 기본설정안에 들어가는 내용입니다.

file ... vagrantfile

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/focal64"
end

1.1.2. 쿠터네티스 구성

쿠터네티스는 아래와 같이 구성하려고 합니다.
설정을 할 때에 network 옵션을 추가해서 노드간 네트워크를 구성합니다.

  • master x1
  • node x2

가상머신을 구성할 때 node.vm.provision 옵션을 통해서 docker를 기본 설치하도록 설정할 수 있습니다.

vagrantfile을 통해서 n개의 node를 만들 수 있습니다. for문을 사용할 수 있습니다.
서버의 cpu, memory 제한에 대해서 설정을 할 수 있지만, 테스트로 사용하는 것이기 때문에 디테일한 설정을 사용하지 않겠습니다.

file ... vagrantfile

Vagrant.configure("2") do |config|
    config.vm.define "master" do |master|
        master.vm.box = "ubuntu/focal64"
        master.vm.network "private_network", ip: "192.168.56.100"
        master.vm.hostname = "master"
        master.vm.provision "docker"
    end

    config.vm.define "node1" do |node1|
        node1.vm.box = "ubuntu/focal64"
        node1.vm.network "private_network", ip: "192.168.56.101"
        node1.vm.hostname = "node1"
        node1.vm.provision "docker"
    end

    config.vm.define "node2" do |node2|
        node2.vm.box = "ubuntu/focal64"
        node2.vm.network "private_network", ip: "192.168.56.102"
        node2.vm.hostname = "node2"
        node2.vm.provision "docker"
end

1.1.3. virtualbox 실행

$ vagrant up

1.1.4. ssh 접속

config.vm.define 되어 있는 정보를 통해서 ssh접속을 할 수 있습니다.

$ vagrant ssh master

1.1.5. 쿠버네티스 설치를 위한 자동 구성

쿠버네티스 설치를 위한 bash 항목 입니다. 해당 내용은 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ 에서 확인할 수 있습니다. 저는 그 내용을 모았습니다.

# /bin/bash
sudo swapoff -a
sudo sed -i '/swap/d' /etc/fstab
sudo apt-get update
sleep 1

sudo apt-get install -y ca-certificates apt-transport-https curl gnupg-agent 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 \
$(lsb_release -cs) \
stable"
sudo apt-get update
sleep 1

sudo apt-get install -y docker-ce=$docker_ver docker-ce-cli=$docker_ver containerd.io
sudo systemctl enable docker
sudo systemctl start docker

# First Permission
sudo mkdir /etc/docker
# sudo chown $USER:docker /etc/docker

# Setup daemon.
sudo cat > /etc/docker/daemon.json <<EOF
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

sudo mkdir -p /etc/systemd/system/docker.service.d

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl enable docker
sudo modprobe br_netfilter
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

sudo sysctl --system

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sleep 1

sudo apt-get install -y kubelet=$k8s_ver kubeadm=$k8s_ver kubectl=$k8s_ver
sudo apt-mark hold kubelet kubeadm kubectl

network 설정

vagrant 로 kubernetes설정 시 네트워크 문제가 발생합니다.
아래 명령을통해서 network 설정을 등록한다.

--node-ip에 등록되는 IP는 해당 node의 IP 를 말합니다. vagrant를 통해서 설치하면, 네트워크가 enp0s8vagrantfile에 설정되어 있는 IP로 할당되어있는 것을 확인할 수 있습니다.

$ echo "Environment=\"KUBELET_EXTRA_ARGS=--node-ip=192.168.56.101\"" >> /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
$ systemctl daemon-reload
$ systemctl restart kubelet
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
Environment="KUBELET_EXTRA_ARGS=--node-ip=192.168.56.101"

docker ps 가 아무것도 안 나올때

쿠버네티스 구성을 끝냈지만, docker ps에서는 아무런 정보도 확인할 수 없을 때, 아래 명령어를 통해서 돌아가고 있는 것을 확인할 수 있습니다.
crictl는 디버깅 툴이지만, docker의 상태를 확인할 때도 유용합니다.

$ sudo crictl pods

본 글은 kubernetes 설치 항목에 이어집니다.

반응형

기본형식

$ kubectl [command] [type] [name] [flags]

COMMAND

  • create
  • get
  • delete
  • edit

TYPE

자원의 타입

  • node
  • pod
  • service

NAME

마음대로 수정가능

예) webserver,

FLAG

부가적인 설정을 할 수 있음.
--help, -o options 등으로 입력할 수 있음.

root@master:/home/vagrant# kubectl get node
NAME     STATUS   ROLES           AGE   VERSION
master   Ready    control-plane   37m   v1.24.1
node1    Ready    <none>          36m   v1.24.1
node2    Ready    <none>          36m   v1.24.1
$ kubectl get node -o wide
NAME     STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
master   Ready    control-plane   40m   v1.24.1   10.0.2.15     <none>        Ubuntu 20.04.4 LTS   5.4.0-113-generic   containerd://1.6.4
node1    Ready    <none>          39m   v1.24.1   10.0.2.15     <none>        Ubuntu 20.04.4 LTS   5.4.0-113-generic   containerd://1.6.4
node2    Ready    <none>          38m   v1.24.1   10.0.2.15     <none>        Ubuntu 20.04.4 LTS   5.4.0-113-generic   containerd://1.6.4
$ kubectl describe nodes master
$ kubectl run webserver --image:nginx:1.14 --port 80
pod/webserver created

# pod 정보확인

$ kubectl describe pod webserver

상세정보로 현재 실행상태를 파악할 수 있습니다.
자세히 살펴보니 네트워크 설정 오류로 판단되어 kubeadm 으로 리셋 후 다시 설정하기로 하였다.

$ kubeadm reset 
$ systemctl restart kubelet

# 2. cni 관련 디렉토리 파일 삭제(마스터에서만)
$ rm -rf /etc/cni/net.d/*
$ rm -rf $HOME/.kube/config
반응형

2년동안 gitlab을 운영하면서 한번도 업그레이드를 하지 않았습니다. gitlab.com 사이트에서는 계속 신기술과 최적화가 이뤄지도 있었지만, 온프로미스에 설치되어 있는 사내 gitlab은 새로운 시대에 적응을 못하고 있었습니다. 그래서, 이번에 버전업을 진행하면서 작업 방법에 대해서 글을 남깁니다.

gitlab 은 업그레이드 주요버전을 넘어서 업그레이드 할 수 없습니다. 설치하려고해도 설치완료 되었다는 메세지를 확인할 수 없습니다. 아래와 같은 메세지 Complete!라는 메세지와 로고가 나와야 합니다.

gitlab Reconfigured!
Restarting previously running GitLab services
ok: run: alertmanager: (pid 29637) 0s
ok: run: gitaly: (pid 9202) 7121s
ok: run: gitlab-exporter: (pid 29649) 0s
ok: run: gitlab-kas: (pid 29612) 1s
ok: run: gitlab-workhorse: (pid 29623) 1s
ok: run: grafana: (pid 29653) 1s
ok: run: logrotate: (pid 29663) 0s
ok: run: nginx: (pid 29672) 1s
ok: run: node-exporter: (pid 29683) 0s
ok: run: postgres-exporter: (pid 29689) 1s
ok: run: postgresql: (pid 1562) 9127s
ok: run: prometheus: (pid 29707) 0s
ok: run: puma: (pid 29794) 0s
ok: run: redis: (pid 8759) 7201s
ok: run: redis-exporter: (pid 29800) 1s
ok: run: sidekiq: (pid 29807) 0s

     _______ __  __          __
    / ____(_) /_/ /   ____ _/ /_
   / / __/ / __/ /   / __ `/ __ \
  / /_/ / / /_/ /___/ /_/ / /_/ /
  \____/_/\__/_____/\__,_/_.___/


Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup

  Verifying  : gitlab-ce-14.10.4-ce.0.el7.x86_64                                                                                                      1/2
  Verifying  : gitlab-ce-14.9.5-ce.0.el7.x86_64                                                                                                       2/2

Updated:
  gitlab-ce.x86_64 0:14.10.4-ce.0.el7

Complete!

1. 준비

1.1. 백업

원복하기 위한 작업입니다. 2년 넘게 작업해온 내역들이 날아갈 수 있습니다. 내용을 작성하면서 다시 한번 백업을 진행했습니다. 백업은 자주 해 주시면 좋습니다. 기왕이면 crontab을 사용해서 작성하시기 바랍니다.

$ gitlab-backup create
2022-07-05 23:04:05 +0900 -- Dumping repositories ... done
2022-07-05 23:04:05 +0900 -- Dumping uploads ...
2022-07-05 23:04:06 +0900 -- Dumping uploads ... done
2022-07-05 23:04:06 +0900 -- Dumping builds ...
2022-07-05 23:04:06 +0900 -- Dumping builds ... done
2022-07-05 23:04:06 +0900 -- Dumping artifacts ...
2022-07-05 23:04:06 +0900 -- Dumping artifacts ... done
2022-07-05 23:04:06 +0900 -- Dumping pages ...
2022-07-05 23:04:06 +0900 -- Dumping pages ... done
2022-07-05 23:04:06 +0900 -- Dumping lfs objects ...
2022-07-05 23:04:06 +0900 -- Dumping lfs objects ... done
2022-07-05 23:04:06 +0900 -- Dumping terraform states ...
2022-07-05 23:04:06 +0900 -- Dumping terraform states ... done
2022-07-05 23:04:06 +0900 -- Dumping container registry images ... [DISABLED]
2022-07-05 23:04:06 +0900 -- Dumping packages ...
2022-07-05 23:04:06 +0900 -- Dumping packages ... done
2022-07-05 23:04:06 +0900 -- Creating backup archive: 1657029839_2022_07_05_14.10.4_gitlab_backup.tar ...
2022-07-05 23:04:06 +0900 -- Creating backup archive: 1657029839_2022_07_05_14.10.4_gitlab_backup.tar ... done
2022-07-05 23:04:06 +0900 -- Uploading backup archive to remote storage  ... [SKIPPED]
2022-07-05 23:04:06 +0900 -- Deleting tar staging files ...
2022-07-05 23:04:06 +0900 -- Cleaning up /var/opt/gitlab/backups/backup_information.yml
2022-07-05 23:04:06 +0900 -- Cleaning up /var/opt/gitlab/backups/db
2022-07-05 23:04:06 +0900 -- Cleaning up /var/opt/gitlab/backups/repositories
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/uploads.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/builds.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/artifacts.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/pages.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/lfs.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/terraform_state.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/packages.tar.gz
2022-07-05 23:04:07 +0900 -- Deleting tar staging files ... done
2022-07-05 23:04:07 +0900 -- Deleting old backups ... [SKIPPED]
2022-07-05 23:04:07 +0900 -- Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.

/var/opt/gitlab/backups 에 백업한 파일들이 있는 것을 확인할 수 있습니다.

1.2. DB 자동 백업 중지

gitlab은 버전업을 하면 DB 또한 버전에 맞춰서 갱신되는 작업을 합니다. 이 부분을 자동으로 갱신되는 것을 방지 합니다. /etc/gitlab폴더에 파일을 생성해 놓으면 gitlab에서 자동으로 백업되는 것을 방지할 수 있습니다.

$ touch /etc/gitlab/skip-auto-backup

2. 업그레이드 작업

2.1. 업그레이드 순서 확인

8.11.Z -> 8.12.0 -> 8.17.7 -> 9.5.10 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15 -> 14.0.12 -> 14.3.6 -> 14.9.5 -> 14.10.Z -> 15.0.Z -> latest 15.Y.Z

여기에 업그레이드 버전에 맞춰서 단계별로 진행해야 합니다. 현재 버전이 중간에 있다면, 그 다음 버전으로 업그레이드 해주면 됩니다.

주의: 한번씩 업그레이드 해 줄때마다 백그라운드 이전작업이 진행 됩니다. 이 부분을 반드시 확인하면서 진행하여야 합니다.
또한 redis 버전, progres 버전 등을 업그레이드 해줘야 하는 경우도 있습니다.

$ yum install gitlab-ce-13.8.8
$ yum install gitlab-ce-13.12.15
$ yum install gitlab-ce-14.0.12

2.2. 업그레이드 전에 백그라운드 업데이트 체크

업그레이드 후에 백그라운드에서 DB 데이터등을 업데이트 하는 작업이 있는지 확인하면서 진행합니다. 작업이 다 끝나지 않았는데 업그레이드를 진행하면 데이터가 깨질 수 있다고 합니다.

2.2.1. bash 명령어로 확인

# 작업 확인
$ sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
0 # 작업중이면 '1'로 표기

2.2.2. 관리자 화면에서 확인

gitlab을 admin계정으로 접속을 한 후,
[Admin Area] - [Monitoring] - [Background Migrations] 에 들어가면 상단 Queue에 현재 작업 또는 대기중인 내역을 확인할 수 있다.

반응형

많은 인터뷰에서 Linux 제작자 Linus Torvalds는 자신의 컴퓨터에서 Fedora를 선호한다고 밝혔습니다. 그러나 왜 그는 “인기있는 리눅스 배포판 데비안을 사용하지 않습니까?”에 대한 대답은 과거 데비안 리눅스에서의 설치 경험에 있다고 말했습니다.

Linus Torvalds는 지난 25 년 동안 리눅스를보다 효율적이고 사용자 친화적인 컴퓨팅 플랫폼으로 만들기 위해 끊임없이 노력하고 있습니다. 그의 창작물은 이제 다양한 사용자에게 서비스를 제공하는 많은 Linux 배포판 형태로 오픈 소스 애호가들에게 제공되고 있습니다.

Linux 및 오픈 소스 소프트웨어는 선택의 아이디어를 지원하며 이들의 원동력이 되었습니다. 그러나 시간이 지남에 따라 인터넷에는 데비안 및 우분투와 같은 기능을 기반으로 한 수많은 Linux 배포판들로 채워지게 되었습니다.

Linux 커널은 Google의 Android를 포함한 오픈 소스 운영 체제의 핵심입니다. Linux 창시자가 사용하는 운영 체제는 무엇일까요?

Linus는 자신이 소유 한 모든 장치에서 Fedora를 사용하기를 좋아한다는 것은 알려져있는 사실입니다. 하지만, 세계에서 가장 인기있는 오픈 소스 데스크탑 운영 체제인 Ubuntu 및 다른 사용자가 선호하는 데비안에 대한 그의 생각을 모를 수도 있습니다.

Linus Torvalds에게 데비안 :

Linus가 데비안을 설치하기 어려워 했다는 것은 재미있는 사실입니다. 실제로 그 일이 있은 후, 몇 년 후 2007년 인터뷰에서 그가 말했습니다.

“미안 하지만, 귀를 닫고 싶을지도 모릅니다. 저는 배포판 설치를 쉽게 해서 커널이 대부분인 내 삶을 이어나가고 싶습니다.”

Linus는 데비안을 "무의미한 연습"이라고 부릅니다. 배포의 중요한 점은 설치가 간단하고 쉬워야 한다는 것입니다.

우분투 리눅스에서 리누스 토발즈 :

또 다른 인터뷰에서 Linus는 Ubuntu Linux에 대해 이야기했습니다. 그는 데비안을 너무 기술적이라고 말하면서도, Windows 및 OS X 백그라운드에서 온 사용자에게 Linux를 친숙하게 만들어 준 Ubuntu에 감사했습니다. 여전히 그는 우분투보다 페도라를 선호합니다.

그가 말하길:

나는 몇년동안 우분투를 몇번 시도했는데, 대부분 우분투가 데비안을 사용할 수 있게 해 줬기 때문이었습니다.

지난 몇 년 동안 데비안은 설치를 더 쉽게하기 위해 노력해 왔습니다. 오늘날 데비안 설치 프로그램은 그래픽, 텍스트 또는 음성 합성 옵션을 제공하여 작업을 단순화했습니다.

반응형

'개발 > 리눅스' 카테고리의 다른 글

ansible - 자동화의 시작  (0) 2022.07.14
Gitlab-CE 업그레이드  (0) 2022.07.05
VIM | Surround.vim 사용하기  (0) 2020.07.09
LINUX | manjaro 설치후 할일  (0) 2020.05.29
LINUX | swap 용량 늘리기  (0) 2020.04.29

Vim 에디터를 사용하고 있다면, 필수로 사용해야 하는 플러그인이라고 생각된다. 괄호, HTML 태그 및 따옴표 같은 값을 몇번의 단축키를 통해서 입력할 수 있다.

설치

surround.vim in awesome-vim 에서 설치방법을 통해서 설치를 진행한다. 별도의 옵션을 설정할 필요없이 바로 사용할 수 있다.

surround.vim

학습 팁

우선, 플러그인 작동 발식을 이해합니다.

  • 감싸기(surround)(ys)
  • 삭제(delete)(ds)
  • 바꾸기(change)(cs)

그리고, 아래에 나와있는 예제를 따라 가세요. 기본 사항들이 이해가 된다면, 코딩에 직접 하시기 바랍니다.

빠르게 개선하기 위해서는 신중한 연습을 필요로 합니다. 매일 약한 부분(ex: 따옴표로 여러단어 추가)을 파악하고, 관련 예제들을 통해 작업하고, 더 많은 예제를 직접 작성 해 봅니다. 그리고, 반복적인 테스트를 진행하시기 바랍니다. 너무 많이 생각할 필요 없이 {motion}단축키를 입력하세요.

며칠동안 하루에 몇분이라도 작업을 한다면, surround.vim을 빠르게 사용할 수 있게 될 것입니다.

  Old text                  Command     New text ~
  "Hello *world!"           ds"         Hello world!
  [123+4*56]/2              cs])        (123+456)/2
  "Look ma, I'm *HTML!"     cs"<q>      <q>Look ma, I'm HTML!</q>
  if *x>3 {                 ysW(        if ( x>3 ) {
  my $str = *whee!;         vllllS'     my $str = 'whee!';

감싸기

한 단어 감싸기

I am happy.
I am "happy".

ysiw"
(ys: 감싸기; iw: 둘러싸고 싶은 단어 위에 커서가 위치한 상태의 전체 단어; ": "로 감싸기

한 줄 감싸기

I am happy; she is sad.
(I am happy; she is sad.)

yss)
(ys: 감싸기 추가; s: 한줄 선택; ) 한 줄을 괄호로 감싼다 )

Note: 만약 yss(로 입력을 하게 되면 괄호 사이에 공간이 추가 된다. ( I am happy; she is sad. )

태그로 단락 또는 한줄 감싸기

Hello World! How are you?
<p>Hello World! How are you?</p>

yss<p>

(yss: 감쌀(surround) 한줄을 선택; <p> 태그를 추가한다.)

다중 단어 감싸기

I am very very happy.
I am *very very* happy.

ys2aw*

(ys: 감싸기 추가; 2: 감쌀 단어의 숫자; aw: 단어 주위; *: *로 깜싼다)

다중 단어 태그로 감싸기

Hello World! How are you?
<h1>Hello World</h1>! How are you?

ys2aw<h1>

다중 단어 감싸기와 동일하다.

선택 영역 감싸기

The solution is x + y = z. You responded wrongly.
The solution is `x + y = z`. You responded wrongly.

veeeeeS`
커서를 단어 x에 위치한 상태로vVisual Mode로 들어 간 후, S 선택 영역을 `로 감싸기

제거

감싸기 삭제

"Hello World!"
Hello World

ds"
(ds: 감싸기 삭제; ": 쌍따옴표 삭제하기

감싼 태그 제거

<em><p>Hello World!</p></em>
Hello World!

dstdst
감싼 태그를 삭제한다. 커서가 안쪽에 있으면, 안쪽 부터 삭제
바깥에 커서가 위치하고 있으면, 바깥 쪽부터 제거한다.

변경

감싸기 변경

"Hello World!"
*Hello World!*

cs"*
(cs: 감싸기 변경; ": 변경 대상자; *: *로 변경)

태그 변경

<p>Hello World!</p>
<em>Hello World!</em>

cst
(cst: 감싸기 변경 태그; <em>: 새로운 태그명)

일반적인 예제

계산식에 괄호 추가하기

3 + 2 + 5 + 7 / 4    # 괄호가 없기에 계산 결과가 달라진다.
3 + 2 + 5 + 7 / 4    # 3에 커서를 위치한 상태에서 veeeeS)iprint
(3 + 2 + 5 + 7) / 4
(3 + 2 + 5 + 7) / 4
print((3 + 2 + 5 + 7) / 4)

메뉴얼 참조

surround.vim에서 기본으로 제공되고 있는 surround.txt에서도 많은 예문을 찾아 볼 수 있다. 이부분만 한번씩 따라해도 어떻게 사용하는 건지 감이 온다.

Old text에 포함되어 있는 *은 커서의 위치다.

  Old text                  Command     New text ~
  "Hello *world!"           ds"         Hello world!
  [123+4*56]/2              cs])        (123+456)/2
  "Look ma, I'm *HTML!"     cs"<q>      <q>Look ma, I'm HTML!</q>
  if *x>3 {                 ysW(        if ( x>3 ) {
  my $str = *whee!;         vllllS'     my $str = 'whee!';

삭제

  Old text                  Command     New text ~
  "Hello *world!"           ds"         Hello world!
  (123+4*56)/2              ds)         123+456/2
  <div>Yo!*</div>           dst         Yo!

변경

  Old text                  Command     New text ~
  "Hello *world!"           cs"'        'Hello world!'
  "Hello *world!"           cs"<q>      <q>Hello world!</q>
  (123+4*56)/2              cs)]        [123+456]/2
  (123+4*56)/2              cs)[        [ 123+456 ]/2
  <div>Yo!*</div>           cst<p>      <p>Yo!</p>
반응형

만자로 설치후 할일

Manjaro 저장소 변경

패키지 미러 서버를 변경해서 빠른 소스 업데이트 적용하자. 조금 시간이 걸리지만, 빠르게 다운로드 적용할 수 있는 점이 있다.

sudo pacman-mirrors --fastrrack && sudo pacman -Syyu

한글 자판 설치

nimf를 포크해서 하모니카 리눅스에서 보완해주고 있습니다.

nimf-git 패키지를 이용해서 설치하여야 합니다.

설치

# 설치를 위한 툴 설치
sudo pacman -S base base-devel yay git
sudo pacman -Syu
yay -S nimf

im-config 세팅

$ vi ~/.xprofile

아래 내용을 추가

export GTK_IM_MODULE=nimf
export QT4_IM_MODULE="nimf"
export QT_IM_MODULE=nimf
export XMODIFIERS="@im=nimf"
nimf

시스템 Reboot

nimf 설치하신 후, nimf-settings 를 실행하셔서 환경 변수 설정 옵션을 disable로 변경 합니다.

만약 다른 입력기를 사용하시려면 환경 변수 설정 옵션을 반드시 꺼주셔야 합니다.

반응형

+ Recent posts