오늘도 한 뼘 더

# 배경  사용 중인 서버에서 도커 이미지를 빌드하면서 디스크 공간이 계속 증가하는 일이 발생하고 이로 인해 제대로 동작이 되지 않는 문제가 발생하였다. 미리 해당 서버에 대한 디스크 알림을 받고 사전에 디스크 여유 공간을 확보하면 해당 문제를 해결할 수 있다고 판단했다.그러나 CloudWatch에서는 기본적으로 현재 디스크에 대한 값을 조회하는 기능을 제공하지 않아서 CloudWatch Agent를 이용한다.   # CloudWatch Agent 설치  AWS에서 제공하는 파일을 다운로드하여서 사용하였다. (yum을 사용하여서는 도저히 설치가 되지 않아서 사용하지 못했는데 방법을 찾아봐야겠다.)$ wget https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu..

# 배경  aws eks를 통해 만들어진 nodegroup을 삭제하는 과정에서 다음과 같은 에러 메시지가 뜨면서 삭제가 되지 않는 문제가 발생했다.   # 문제  pod가 삭제되는 중에 pending 문제가 발생하여 해당 에러가 발생할 수 있다는 걸 알았고 명령어로 검색한 결과 다음과 같이 pod들이 pending이 되고 있었다. 이중 해당 문제를 발생시키는 pod는 ebs-csi-controller pod이다.   # 해결 방법  ebs-csi-controller pod를 삭제한 후 nodegroup을 삭제하도록 한다.$ kubectl delete deployment ebs-csi-controller$ eksctl delete nodegroup --cluster [CLUSTER] --name [NODE..

# 배경  제플린 쿼리를 돌리는 중 다음과 같은 에러가 발생하였다.Output is truncated to 220000 bytes. Learn more about ZEPPELIN_INTERPRETER_OUTPUT_LIMIT   # 원인  결과 내용이 설정해 둔 것보다 커서 나오는 에러였다.   # 해결 방법  output limit을 더 큰 값으로 변경해서 해당 문제를 해결하도록 한다. 1. 서버에 접근한다.$ ssh ubuntu@[server IP] 2. zeppelin 도커에 접근한다.$ docker exec -it zeppelin /bin/bash 3. zeppelin-sites.xml 에서 설정 값을 변경한다.$ vi conf/zeppelin-site.xml밑의 값을 변경 zeppelin.int..

1. docker 그룹 확인하기 docker 그룹 확인$ cat /etc/group | grep -i docker docker:x:221:root 아무 결과도 나오지 않는다면 docker 그룹이 없는 것이기 때문에 docker 그룹을 생성해줘야 한다.$ sudo groupadd docker$ sudo systemctl restart docker 2. 사용자 계정을 docker 그룹에 추가$ sudo usermod -aG docker [user] -G 옵션사용자 계정의 소속 그룹을 변경하는 데 사용하는 옵션여러 그룹을 지정할 때는 , 로 구분한다  -a 옵션사용자 계정을 변경하지 않고 추가하는 옵션 3. 사용자 계정이 잘 추가되었는지 확인$ id -a [user]> uid=1001(user) gid=100..

# 배경  eksctl 명령어를 통해서 AWS EKS 서비스에 클러스터를 생성하는 작업을 진행했다. 클러스터의 버전을 config 파일에 명시해서 진행을 하는 중에 다음과 같은 에러가 발생하였다. apiVersion: eksctl.io/v1alpha5kind: ClusterConfigmetadata: name: test region: ap-northeast-2 version: "1.29"   # 문제  eksctl 명령어를 사용하여 클러스터를 생성하는 중 다음과 같은 에러가 발생하였다. Error: invalid version, supported values: 1.21, 1.22, 1.23, 1.24 eksctl 버전에 따라 지원하는 쿠버네티스 버전이 다른데 구 버전의 eksctl을 사용..

# 배경 로컬에서 서버를 ssh로 접근하고 일정 시간 입력이 없으면 다음 메시지가 뜨면서 연결이 끊기게 된다. 이 시간이 생각보다 짧아서 스크립트가 돌아가는 중 연결이 끊길까 엔터키를 몇 번 쳤던 경험이 있다. 이 시간을 늘리도록 해보자 $ client_loop: send disconnect: Broken pipe # connection 시간 늘리기 위와 같은 현상은 서버가 클라이언트가 살아있는지 확인을 하는데 응답이 없을 때 발생하기에 이 시간과 횟수를 늘리면 된다. SSH 설정 파일에 접근한다. $ sudo vi /etc/ssh/sshd_config 아래와 같이 설정값을 활성화 및 작성한다. 300초 * 3 = 900초 동안 클라이언트에게 응답을 요청한다. ClientAliveInterval 300 ..

# 배경 helm update를 통해서 백엔드 서비스 업데이트를 진행할 때 따로 설명에 대한 명령어를 넘기지 않으면 `helm history`를 통해서 내용을 확인할 때 Description에 Upgrade complete로 나온다. # Helm update에 설명 추가하기 --description 옵션을 사용한다. $ helm upgrade [name] Chart.yaml -f file.yaml --description "deploy test" 위에 description이 제대로 적용됐는지는 history를 통해 가능하다 $ helm history [name]

# 배경 mysqldump를 사용할 때 특정 컬럼만 선택하는 방법은 없다. 특정 컬럼을 백업해서 넘기기 위해서는 temp 테이블을 만들어서 temp 테이블에 원하는 데이터를 삽입해서 temp 테이블을 덤프 해서 진행하도록 한다. # 스크립트 내용 https://github.com/baekji919/DevOps/tree/main/Data_Backup DevOps/Data_Backup at main · baekji919/DevOps Contribute to baekji919/DevOps development by creating an account on GitHub. github.com ## temp 테이블 생성 sql use database; INSERT into database.table SELECT c..

# 배경 처음 cluster를 서버에서 cli를 통해 생성하거나 기존의 cluster를 config에 업데이트할 때 context의 이름이 해당 클러스터의 arn으로 적히게 된다. context를 명시해서 kubectl 명령어를 작성할 때 다 작성할 수 없기때문에 원하는 이름으로 변경해서 사용하도록 한다. # kubeconfig context 이름 변경하기 ## context 조회하기 $ kubectl config get-contexts ## context 이름 변경하기 $ kubectl config rename-context [old_name] [new_name] ex) $ kubectl config rename-context arn:... test

# 배경 헬름 차트를 사용하여 올린 리소스들에 대해서 autoscaling 관련 값들을 수정하기 위해서 values.yaml 파일을 수정하고 helm upgrade 명령어를 사용하였는데 값이 적용되지 않는 것을 확인하였다. 처음에는 kubectl의 client와 server 버전이 맞지 않아 발생한 문제라고 생각을 하였으나 명령어 입력 과정에서 나온 실수로 인한 문제였다. # 문제 및 해결 방안 helm upgrade 명령어 작성 시 values.yaml도 같이 작성을 해줘야 하는데 Chart.yaml 경로만 명시를 하고 values.yaml을 따로 작성하지 않았다. 문제의 명령어 $ helm upgrade jihyun ../helm-chart/ --kube-context=test -n test 올바른 ..