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

How to remove directories from Mac Mac의 임시 파일들을 삭제하는 방법을 게시했던 ._xxx, .DS_Store 등 숨김파일 정리 및 .gitignore 처리하기 에서 언급했던 방식을 응용해서 Node 기반의 개발에서 사용했던 node_modules 디렉터리를 일괄 삭제하는 방법을 정리해 본다. 개발하면서 참조한 소스들, 개발한 소스들이 많기 때문에 특정 경로 이하의 모든 node_modules 들을 찾아서 삭제하는 것보다는 일괄적으로 삭제 하기 위해서 find 명령을 사용하면 된다. $ find . -name "node_modules" -type d -prune -print -exec rm -rf '{}' + find . : 현재 경로를 루트 경로로 설정하고 검색 -name "node_modules" : "node_modules"라는 이름을 지정 -type d : 지정한 이름의 디렉터리만 찾도록 지정 -prune : "node_modules"가 발견되면 그 경로 하위로 내려가지 않도록 지정 -print : 검색된 대상의 경로 출력하도록 지정 -exec rm -rf '{}' + : 일치된 결과에 대한 삭제 처리를 수행하는데, {} + 는 마지막에 선택한 이름을 추가해서 명령줄을 빌드하도록 하는 것으로 전체 발견된 "node_modules"의 수보다 적은 횟수로 호출할 수 있도록 조정하는 것으로 성능 향상을 위한 것이다. 무조건 실행되면 다시 복구할 수 없는 상태 가 되므로 아래의 명령으로 실제 대상들이 제대로 검색되는지를 먼저 확인하고 진행하도록 한다. $ find . -name "node_modules" -type d -prune -print | xargs du -chs 254M ./K3Lab/RNDWorks/apigw/samples/etri/web/node_

How to set compinit mode on zsh KinD (Kubernetes in Docker)로 MacOS 상에 Multi-Nodes Kubernetes Cluster를 구성 하면서 kubectl autocomplete를 설정했는데 아래와 같은 메시지가 터미널 실행 시에 계속 나타나는 문제가 발생했다. zsh compinit: insecure directories, run compaudit for list. Ignore insecure directories and continue [y] or abort compinit [n]? 정보를 찾아보니 대 부분 zsh와 관련된 소유권 문제를 많이 이야기하고 있었다. 즉, 외부의 패키지나 라이브러리 등을 설치할 떄 외부의 스크립트를 사용할 경우에 /usr/local/share 폴더의 소유권과 권한이 변경 되는 문제로 발생한다는 것이다. 상황을 확인해 보기 위해서 아래의 명령을 수행한다. $ compaudit There are insecure directories: /usr/local/share 또는 There are insecure directories: /usr/local/share/zsh/.site-functions /usr/local/share/zsh 위의 같은 결과를 확인할 수 있다. 결과를 바로 소유권 및 권한 처리를 하는 방법은 다음과 같다. # 검증 및 변경 처리 $ compaudit | xargs chmod g-w # 재 검증 $ compaudit There are insecure directories: 위의 방법이 아니라 개별적으로 처리하는 경우는 다음과 같다. /usr/local/share/zsh/.site-functions 가 나온 경우 $ cd /usr/local/share/zsh $ sudo chown -R root:root ./site_functions /usr/local/share 가 나온 경우 $ cd /usr/local/share/

How to remove temporary hidden files like .DS_Store / ._xxxx Remove ._xxxx files MacOS에서 여러 작업을 하다보면 ._ 으로 시작하는 파일들이 생성된 것을 확인할 수 있다. (일반적으로 숨김 파일들이라 보이지 않는다) 이런 파일은 다양한 작업 중에 생성되는데 일반적인 상황은 다음과 같다. MacOS HDD/SDD에서 외장 HDD/SDD로 복사했을 때 MacOS에서 압축했을 때 더 많은 상황이 있을 수 있지만 결국은 다른 플랫폼 (또는 다른 FileSystem)과 혼용할 경우에 아이콘을 생성하기 위해 파일을 가져오는 과정에서 메타정보 저장용으로 자동 생성된다. 이런 파일의 생성과 제거는 다음과 같은 방법들이 존재한다. 압축하는 경우라면 다른 플랫폼에서 이런 파일들이 유지되지 않도록 COPYFILE_DISABLE 설정을 하면 된다. # 압축 명령에서 사용해서 tar가 메타 정보를 추가하지 않도록 설정 $ COPYFILE_DISABLE=1 tar -cf xxxx.tar file* 매번 이렇게 처리하는 것이 귀찮다면 아예 shell에 설정하는 것도 가능하다. # ~/.zshrc 또는 ~/.bash_profile, .... ... COPYFILE_DISABLE=1; export COPYFILE_DISABLE ... 이미 파일이 존재하는 경우라면 일괄 삭제할 수 있다. $ find ./ -name ._\* -delete Git에서 MacOS의 불필요 파일들 제외하기 위에서 설명한 것과 같이 자동 생성되는 파일들을 git 에서 제외하려면 .gitignore 파일을 사용하면 된다. git에 포함되지 않도록 제외하는 경우 # .gitignore 파일 ... # OS Generated Files # ###################### **/.DS_Store **/._* ... 이미 git에 포함된 경우 # git 정보 검색 및 삭제 $ find . -name

# How to force deletion of a namespace ## 문제 상황 Argo Project의 Argo Events를 테스트해 보기 위해서 여러 가지 작업을 하던 중 제대로 처리가 되지 않아서 다시 시작할 겸 Namespace를 삭제해서 소속된 리소스들을 모두 삭제했다.  그런데 위의 그림처럼 Argo Events Namespace가 삭제되지 않고 `Terminating` 상태로 계속 유지되는 문제가 발생했다. ## 문제 원인 정상적으로 삭제될 수 있는 시간을 지나서도 `Terminating` 상태로 남아있어서 원인에 대한 부분을 찾다가 Namespace의 다른 모든 Resource들은 삭제되었는데 (정확하게는 Dashboard에도 조회가 되지 않고, kubectl get 명령으로도 보이지 않는) Namespace만 저런 상태라서 Namespace에 대한 정보를 출력해 보았다. ```bash # Resource 정보 출력 $ kubectl get namespace argo-events -o yaml apiVersion: v1 kind: Namespace metadata: creationTimestamp: "2021-01-13T10:40:07Z" deletionTimestamp: "2021-01-15T09:31:30Z" ... spec: finalizers: - kubernetes # Namespace에 대한 Finalizers status: conditions: - lastTransitionTime: "2021-01-15T09:31:36Z" message: All resources successfully discover

How to building real world sample step by step - Part 3 게시글 참고 이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다. PART 1 에서는 부트스트랩 노드 구성 PART 2 에서는 클러스터에 노드들이 참여할 떄 사용할 서비스와 설정등을 구성하고 StatefulSet을 구성 이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 구성된 Galera Cluster의 사용하지 않는 bootstrap 정보를 제거하고, 외부 연결을 위한 서비스 생성 및 서비스의 중단없이 Scale Up/Down 할 수 있도록 나머지 부분을 적용해 본다. 이 과정까지 완료되면 프로덕션 환경에 적용할 수 있는 정도가 된다. Cleanup bootstrap node PART 2 에서 모든 노드들을 클러스터에 참여시켰기 때문에 더 이상은 부트스트랩 노드가 필요하지 않다. 따라서 operator.yaml 에 부트스트랩 노드와 관련된 리소스를 제거하는 Step과 Task를 추가하도록 한다. ... plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: ... - name: cleanup # 추가 tasks: - bootstrap_cleanup tasks: ... - name: bootstrap_cleanup # 추가 kind: Delete spec: resources: - bootstrap_deploy.yaml - bootstrap_service.yaml - bootstrap_confi

How to building real world sample step by step - Part 2 게시글 참고 이 게시글은 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 처리하고 동작을 검증하면서 정리한 내용입니다. PART 1 에서는 부트스트랩 노드 구성 PART 3 에서는 사용하지 않는 부트스트랩을 제거하고, 외부 접속을 위한 서비스를 생성하며, 안전한 Scale Up/Down 처리 구성 이 문서는 KUDO Blog 샘플을 기준으로 테스트하면서 발생한 문제점들을 해결하고 동작을 검증하면서 정리한 내용으로 초기 구성된 Galera Cluster의 부트스트랩을 이용해서 클러스터에 노드들이 참여할 떄 사용할 서비스와 설정등을 구성하고 StatefulSet을 구성하는 방법을 정리한다. Cluster에 참여하는 Node를 위한 초기 설정 구성 operator.yaml 파일에 아래와 같이 firstboot_config 라는 Step과 Task를 추가하도록 한다. apiVersion: kudo.dev/v1beta1 appVersion: 0.1.0 kubernetesVersion: 0.16.0 kudoVersion: 0.17.2 maintainers: - email: ccambo@gmail.com name: ccambo name: galera-operator operatorVersion: 0.1.0 plans: deploy: strategy: serial phases: - name: deploy strategy: serial steps: - name: bootstrap_config tasks: - bootstrap_config - name: bootstrap_service tasks: - bootstrap_service -

[Kubernetes - Storage] How to configure a dynamic storage provisioner for Kubernetes using a network file system on CentOS 8 참고 이 문서는 Network File System을 CentOS 8에 설치하여 NFS Server로 운영하면서 Kubernetes의 PVC (Perssistent Volume Claim) - StorageClass - NFS 로 연동되는 PV (Persistent Volume)를 자동으로 구성하는 방법을 정리한 것입니다. CentOS 8에 설치되는 NFS를 Kubernetes의 Dynamic Storage Provisioning 으로 활용해서 PV (Persistent Volume)를 구성해 본다. Network file system 구성 NFS 서버를 구성하는 부분은 CentOS 8에 NFS 설정 및 테스트 글을 참고해서 진행하도록 한다. NFS 서버는 물리적인 머신으로 네트워크 상에 존재하면 되며, Network을 통해서 Kubernetes Cluster에서 NFS 서버로 접근할 수 있어야 한다. 위에서 구성한 NFS 서버를 사용할 수 있도록 처리하는 NFS Provisioner Pod가 Kubernetes Cluster에 PV를 배포할 수 있도록 하기 위해서는 필요한 권한 설정이 필요하다. 따라서 PV를 배포할 수 있도록 ClusterRole, ClusterRoleBinding, Role, RoleBinding 설정을 가지는 Service Account를 생성해 줘야 한다. Service Account 생성 서비스 계정을 생성한다. (serviceaccount.yaml) apiVersion: v1 kind: ServiceAccount metadata: name: nfs-provisioner 아래의 명령을 사용해서 Kubernetes에 적용한다. $ kubectl apply -f serviceaccount

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는 계정