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