MSFL :: 모리스 소프트웨어 공작소

How to set up a network file system on CentOS 8 클라이언트 / 서버 파일 시스템이라고도 부르는 NFS (Network File System)는 클라이언트가 네트워크를 통해 다른 사용자와 디렉토리 및 파일을 공유하고 상호 작용할 수 있도록 마치 로컬에 마운트된 것 처럼 네트워크를 통해 로컬 파일 시스템을 내보내는데 널리 사용되는 교차 플랫폼 및 분산 파일 시스템 프로토콜이다. 두 대의 머신에 CentOS 8을 설치하고 NFS 설정을 통해서 클라이언트 / 서버간의 파일 공유를 검증해 본다. NFS Server 구성 NFS (Network File System)는 네트워크 상의 다른 머신에서 파일 시스템으로 마운트하여 사용할 수 있도록 공유하는 방법이다. NFS 서버 패키지 설치 # 이미 설치되어 있는 경우는 최신 버전으로 업그레이드 된다. (nfs-utils-1:2.3.3-35.el8.x86_64) $ sudo dnf install -y nfs-utils NFS 서버 Exports 설정 공유할 디렉터리를 구성한다. $ sudo mkdir /data/NFS NFS 서버의 특정 IP 호스트 접속을 허용하는 설정을 구성한다. (/etc/exports) $ sudo vi /etc/exports /data/NFS 10.0.1.*(rw,sync,no_root_squash) 주의 위의 /etc/exports 파일 내에 옵션을 설정할 때는 빈 공백이 없이 붙여서 작성해야 한다. 10.0.1.* 는 10.0.1.0/24 와 같은 의미로 어떤 것을 사용해도 좋다. 사용할 수 있는 옵션들은 다음과 같다. rw : 읽기 및 쓰기 가능 ro : 읽기만 가능 secure : 클라이언트 마운트 요청시 포트를 1024 이하로 지정 noaccess : 액세스 거부 root_squash : 클라이언트의 root 사용자가 서버의 root 권한을 획득하는 것을 방지 no_root_squach : 클라이언트의 r

[Git] How to initialize remote repository 주의 아래의 정리된 명령들을 수행하면 원격 저장소의 데이터가 모두 초기화되므로 미리 백업등을 해 놓고 진행해야 한다. 가장 기본적인 방법은 새로운 Repository를 만들고 다시 remote server 연결하는 것이지만, Repository에서 많은 수의 파일을 삭제하고 현재 상태로 Repository를 재 구성(초기화)해야 할 경우도 존재한다. 여기서는 기존에 계속 사용 중이던 Remote Repository를 현재 상태로 Repository를 재 구성하는 경우를 정리한다. (전체적인 과정은 초기 git 구성하는 방식과 크게 다르지 않다) 로컬에 존재하는 프로젝트 디렉터리에서 숨겨진 .git 서브 디렉터리를 삭제한다. # .git 디렉터리 삭제 $ rm -rf ./.git git init 을 다시 수행해서 git를 초기화 한다. # git 초기화 $ git init 현재 상태로 commit 을 진행한다. # 현재 경로의 모든 파일/디렉터리들 추가 $ git add . # 추가된 정보들에 대한 커밋 $ git commit -m "<commit comment>" remote repository 를 연결한다. # remote repository 연결 $ git remote add origin <url> # 연결된 remote repository 확인 $ git remote -v 참고 만일 github의 여러 계정을 사용하는 경우는 macOS에서 여러 개의 Github.com 계정 사용하기 글에서와 같이 SSH를 사용한다면 ssh config 파일 설정 과 사용방법 을 참고해서 <url>을 맞춰줘야 한다. 현재 상태를 push 한다. $ git push --force --set-upstream origin master 참고 Branch를 새로 생성해서 push한 후에 기존 B

[Git] How to use multiple account of github on macOS github에 여러 개의 계정이 있고, Visual Studo Code나 터미널에서 사용하다 보면 Permission error 나 User Denied 등의 오류를 만날 수 있다. 이런 문제들을 해결하고 SSH Key를 이용해서 여러 개의 github 계정을 설정하고 사용하는 방법을 정리해 놓는다. 문제점 단일 계정만 사용할 경우라면 pull, push를 처음할 때 계정 권한을 확인하는 프롬프트가 뜨고, 계정 정보를 입력하면 키 체인 에 보관되기 때문에 다음 부터는 입력하지 않아도 정상적으로 처리가 된다. 그러나 또 하나의 계정을 더 만들어서 Repository 동기화를 하려고 하면 키 체인에 저장된 정보 때문에 이전 계정의 정보를 사용하기 때문에 계속 오류가 발생하게 된다. 해결 방법 해결 방법은 간단하다. 각 계정에 대한 SSH Key 생성하고 github에 등록해서 관리하면 각 계정별 Repository에 대한 걱정 없이 편리하게 사용할 수 있다. 우선 Remote Repository를 확인해 보도록 하자. # 현재 설정된 원격 저장소 보기 $ git remote -v # 현재 저장소 설정 조회 (저장소 루트 폴더에 .git/config 파일에 정보가 존재한다) $ git config --list 기존에 입력되어 있는 키 체인 정보 삭제 Spotlight 검색(F12) 등으로 키체인 접근 앱 실행  키체인 접근 앱에서 로그인 을 선택하고 github.com 을 찾아서 삭제 참고 macOS는 SSH 키들을 ~/.ssh 디렉터리에 관리한다. 이후 작업은 모두 이 경로에서 처리하는 것을 기준으로 한다. github는 계정

[Vue] Keypoints of Vue 프로젝트에서 사용할 Front-End Framework을 고심하던 중에 Gregg이 Vue.js를 소개하는 공식 자료를 보고 Vue를 선택했다. 아래의 내용은 참고자료에 언급한 원문을 번역하면서 나름대로 정리한 것으로 왜 Vue가 43%의 개발자들이 vue.js를 배우려고 하는지를 알 수 있다. 참고 현재 TOP 3 (Angular, React, Vue)의 자바스크립트들에 대한 비교는 vue.js 공식문서 를 참고하면 된다. 점진적인 프레임워크 Vue는 진입장벽이 낮고, 유연하고, 성능이 우수하고, 유지보수와 테스트가 편한 자바스크립트 프레임워크로 점진적인 프레임워크를 지향 하고 있다. 점진적인 프레임워크라는 것은 웹 어플리케이션 전체를 한꺼번에 하나의 프레임워크 구조로 구조화하지 않아도 일정 부분만 적용 가능 해서 사용자에게 더 좋은 사용자 경험을 제공할 수 있다는 것을 의미한다. 물론 전체를 처음부터 Vue로 구현할 수도 있다. Vue가 큰 규모의 어플리케이션을 개발할 수 있도록 핵심 라이브러리와 주변 생태계를 제공하고 있다. 재 사용 가능한 컴포넌트 (단일 파일 컴포넌트) 다른 프레임워크들처럼 재 사용이 가능한 컴포넌트로 웹 페이지를 구성할 수 있으며, 각 컴포넌트는 페이지 영역을 표시하는데 필요한 HTML, CSS, Script 를 가지는 단일 파일 컴포넌트 구조를 제공한다. 프로젝트로 알아보기 아주 간략하고 특징적인 Vue의 주요 컨셉을 알아볼 수 있다. 대 부분의 자바스크립트와 같이 페이지에 데이터를 표시하는 것부터 시작한다. 위의 그림에 표시된 것과 같이 "X"의 위치에 스크립트에서 설정한 "Boots"를 표시하고 싶으면 아래와 같이 구현하면 된다. 위의 내용을 좀 더 자세히 확인하면 다음과 같다. 정보를 표시할는 것은 Vue의 데이터를 바인딩할 때 사용하는 {{ ... }} 를 사용한다. 위의 예는 Vue 에서 관리하는 데이터 중에

How to building real world sample step by step - Part 1 게시글 참고 이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다. PART 2 에서는 Galera Cluster에 참여할 노드들 구성 PART 3 에서는 사용하지 않는 부트스트랩을 제거하고, 외부 접속을 위한 서비스를 생성하며, 안전한 Scale Up/Down 처리 구성 이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 Galera 클러스터 구성을 위한 Bootstap Node 설정을 다룬다. 참고 이 문서는 KUDO에 대한 이해를 어느 정도 하고 있다는 것을 전제로 하며 MariaDB의 오픈 소스 클러스터링 솔루션인 Galera를 위한 Operator를 KUDO를 이용해서 만드는 과정을 정리한 것이다. 이 문서는 KUDO v0.17.0 기준으로 작성되었다. KUDO에 관련된 정보는 이전 글들 참고 KUDO 정리 (Kubernetes Universal Declarative Operator - Kudobuilder) KUDO 설치 및 간단한 사용법 검증 KUDO CLI 명령어 정리 환경 설정 파일 시스템 레이아웃 구성 우선 작업할 내용은 개발 및 테스트 환경을 구성하는 것이다. 이전 글들에서 언급했던 것과 같이 아래와 같은 구성이 필요하다. (KUDO-CLI 명령을 통해서 구조 및 기본 파일들을 생성할 수 있다.) 작업할 대상은 ~/kudo_sample/galera-operator 폴더를 기준으로 한다. . └── operator ├── operator.yaml ├── params.yaml └── templates 2 directories, 2 files 생성된 operator.yaml 파일은 아래와 같이 구성한다. apiVersion: kudo.de

유동 (Floating) IP 관련 명령들 유동 IP 생성 오픈스택 대시보드를 통해서도 유동 IP를 생성할 수는 있지만 랜덤하게 생성되는 문제가 았기 때문에 CLI를 이용해서 연속적인 IP를 할당할 수 있다. 대시보드 유동 IP 생성 왼쪽 메뉴 트리에서 네트워크 > Floating IP 화면을 열고 상단의 프로젝트에 IP 할당 버튼을 눌러서 생성 가능 openstack floating ip create [--subnet <subnet>] [--port <port>] [--floating-ip-address <ip-address>] [--fixed-ip-address <ip-address>] [--description <description>] [--project <project> [--project-domain <project-domain>]] <network> --subnet : 유동 IP (이름 또는 ID)를 만들려는 서브넷 네트워크 지정 (버전 2만) --port : 유동 IP (이름 또는 ID)와 연결될 포트 지정 (버전 2만) --floating-ip-address : 만들 유동 IP 지정 (버전 2만) --fixed-ip-address : 유동 IP가 연결될 고정 IP 주소 (버전 2만) --description : 유동 IP 설명 (버전 2만) --project : 소유지의 프로젝트 (이름 또는 ID) (버전 2만) --project-domain : 프로젝트가 속한 도메인 (이름 또는 ID), 프로젝트 이름이 충돌할 경우에 사용 (버전 2만) network : 유동 IP를 할당할 네트워크 (이름 또는 ID) 유동 IP 삭제 $ openstack floating ip delete <floating-ip> [<floating-ip> ...] floating-ip

How to use KUDO 당연한 것이지만 KUDO를 테스트하기 위해서는 Kubernetes Cluster가 존재해야 한다. Kind 와 Minikube 를 사용할 수 있다. Setup a Kubernetes Cluster 1.13+ Install kubectl 1.13+ Install cert-manager . KUDO는 TLS가 필요한 webhook 를 사용한다. 참고 Minikube Minikue를 통해 KUDO를 로컬에서 개발하고 테스트하기 위해서는 적절한 양의 메모리가 필요한데 Minikube는 2G 메모리를 기준으로 하는데 Kafka의 경우는 최소 10GB를 권장하므로 로컬에서 메모리를 구성하기는 좀 힘들다. 그러나 가능한 리소스가 존재한다면 아래와 같이 기본적인 설정을 바꿔 실행이 가능하다. $ minikube start --cpus=4 --memory=10240 --disk-size=40g Kind KIND를 storage operator와 같이 사용하기 위해서는 KIND v0.7.0 이상을 사용해야 한다. Cert-Manager cert-manager 의존성을 테스트 환경에서 제외할 경우는 KUDO를 보안이 되지 않는 상황으로 자체 서명된 CA 번들을 사용하도록 초기화할 수 있다. $ kubectl kudo init --unsafe-self-signed-webhook-ca 이와 관련된 개발을 위해서 Blog post 를 참고하는 것이 좋다. Install KUDO CLI KUDO CLI 는 kubectl에 KUDO 기능을 제공하는 플러그인이다. CLI 바이너리를 Release Page 에서 다운로드해서 설치가 가능하다. 맥인 경우는 brew 를 통해서 설치가 가능하다. $ brew tap kudobuilder/tap $ brew instll kudo-cli 참고 맥 OSX에서는 명령 사용을 명시적으로 허가해야 할 수도 있으므로 Apple support site 를 참고하도록 한다. 다른 방

How to use Operator tools on Kubernetes 지난 게시글인 Kubernetes상의 Operator 나름대로 정리 에 이어서 Operator 구현하는 툴들에 대해 정리한다. Kubernetes를 Operators 관점에서 보면... Orchestrate stateful applications using K8s API Extend API using Custom Resource Definitions Encode domain specific operational knowledge Upgrades Failure and Recovery Scenarios Scaling up / down Purpose built per application Kubernetes is an Operations API 여러 상황들 검토 Kubernetes에 애플리케이션을 배포하는 것은 다양한 형태로 제공된다. 배치 패러다임, YAML 템플릿처리, IaC (Instrastructure as Code) Tooling (ansible, terraform), Controller 등에 대해서 검토한다. IaC IaC 툴들은 애플리케이션과 클라우드 인프라를 관리하는데 도움이 된다. 개발자는 이 툴들을 통해서 Kubernetes의 리소스들을 관리할 수 있다. 사용자는 이 툴들을 설치 및 유지보수 도구로 활용할 수 있다. 대표적인 것이 Ansible 과 Terraform 등이며, 다른 툴들도 많이 존재한다. 이 툴들은 가상머신이나 애플리케이션을 배포하는데 종종 사용되며 이런 자원들을 설명하는데 cattle (소 떼) vs. Pets (반려동물) 패턴을 사용한다. 소 떼는 교체가 쉽고 상태가 중요하지 않은 구성 요소들을 의미하고 주로 웹 서비스, APIs, Jobs 등을 의미한다. 반려동물은 데이터베이스를 포함해 교체나 갱신이 어려운 구성 요소들을 의미한다. IaC 툴들은 위의 두 가지 유형의 애플리케이션을 비슷하게 다루기 때문에 설치한 이후의

What is the Operator on Kubernetes 기본 전제 및 용어 정리 Kubernetes는 선언적 상태관리 시스템이다. Operator란 Kubernetes 애플리케이션을 패키징, 배포, 관리하는 방법론이다. (운영자 관점) Operator Pattern은 Kuberentes에서 Operator 방법론을 적용해서 확장하는 패턴이다. (확장 개발 관점) Oeprator Framework은 Kubernetes에서 Operator를 실제 구현과 관리를 지원하는 Framework이다. (실 구현 관점) CRD (Custom Resource Definition)은 Operator로 사용할 상태 관리용 객체들의 Spec을 정의한다. (Schema 관점) CR (Custom Resource)은 CRD의 Spec을 지키는 객체들의 실제 상태 데이터 조합이다. (Desired State 관점) CC (Custom Controller)는 CR의 상태를 기준으로 현재의 상태를 규정한 상태로 처리하기 위한 컨트롤 루프다. (Current State 관점) Let's take a look at the conclusion. Operator는 운영자 주로 하는 작업들을 묶어서 자동화하는 것이 목표 이며 다음과 같이 동작하게 된다. 운영자의 입장에서 관리할 대상에 대한 규정 (Spec)을 정의하고 Kubernetes에 등록한다. (Kubernetes의 CRD로 생성) 관리할 대상이 유지해야 할 상태 정보를 규정에 맞도록 지정하고 Kubernetes에 등록한다. (Kubernetes의 CR 객체로 생성 - 상태 데이터로서 ETCD에 저장관리) 상태 유지를 위한 컨트롤러를 구성해서 Kuberentes에 등록 (Kubernetes의 CC로 생성 - 원하는 상태 유지 작업) CRD 방식을 사용하면 일반적인 Kubernetes 사용법 (kubectl - API Server)으로 운용이 가능하며 CRD로 등록된 리소스 객체를 그대로 사용