지식은 날리지

EC2 서버와 S3 버켓은 구축 되어 있다고 가정하고 시작한다.

안 되어 있다면

https://yes5.tistory.com/29

https://yes5.tistory.com/30

먼저 s3와 통신이 되는지 확인해 본다.

aws s3 ls

aws configure를 지정하지 않아

Unable to locate credentials. You can configure credentials by running "aws configure".

에러가 발생한다.

IAM 검색 > 엑세스 관리 > 사용자

사용자 생성 클릭

IAM 권한에 관한 게시물이 아니기 때문에 test용 계정을 생성한다.

사용자 이름 : test등 임의로 설정

AWS Management Console에 대한 사용자 엑세스 권한 제공 > IAM 사용자를 생성하고 싶음

콘솔 암호 > 사용자 지정 암호

다음

사용자 생성

사용자 목록으로 돌아가기

계속

사용자 이름 클릭

보안 자격 증명 > 엑세스 키 > 엑세스 키 만들기

CLI 체크 다음

엑세스 키 만들기

엑세스 키 및 비밀 엑세스 키 확인

비밀 엑세스 키는 이 화면에서 한번 확인 후 확인이 불가능 하니 따로 저장해 놓는다.

엑세스 관리 > 사용자 그룹 > 그룹생성

그룹 이름을 설정하고, 방금 만든 계정을 추가, AdministratorAccess 정책 선택 후 그룹 생성

이제 다시 xshell로 돌아가

aws configure

1. 엑세스 키 복붙

2. 비밀 엑세스 키 복붙

3. ap-northeast-2 ( 해외 리전의 경우 알맞게 입력 )

4. 엔터

aws s3 ls

s3와 통신이 되는 것을 확인

touch test.txt
echo "test" > test.txt

# aws s3 cp test.txt ( S3 버켓 명과 도착지 경로 및 파일명 입력 예시 : s3://kimohseong-test/test.txt )
aws s3 cp test.txt s3://kimohseong-test/test.txt

AWS 콘솔 화면에서 S3 버켓 접속 후 파일 복사 확인

EC2 - S3 간 파일 복사는 위 설명대로 하면 될것이다.

이제 crontab과 bash 스크립트를 이용해 로그 백업 시스템을 만들어보자.

EC2 검색 > 인스턴스

용량 증설 할 인스턴스 ID 클릭 (test2)

스토리지 탭 > 볼륨 ID 클릭

볼륨 선택 > 작업 > 볼륨 수정

크기 지정 10 > 20

옵티마이징하는 동안 시간이 소요된다.

일정 시간 기다리면 크기가 10 > 20 GB로 변경 됐고, 사용 중으로 표시된다.

df -Th

ec2 서버에 접속해서 확인 해보면 여전히 10G.

lsblk

lsblk 명령어로 20G 확인 및 디스크 유형 확인 (xvda or nvme)

# xvda의 경우
sudo growpart /dev/xvda 1

# nvme의 경우
sudo growpart /dev/nvme0n1 1

# xvda, nvme 동일
sudo xfs_growfs -d /

20G 증설 확인

보통 EC2 인스턴스를 생성하거나, 복제할 때 키 페어를 생성 및 선택한다.

혹은 EC2 검색 > 네트워크 및 보안 > 키 페어에서 키 페어 생성 및 수정이 가능하다.

ssh client로 xshell 사용자는 .pem

putty 사용자는 AWS 인스턴스 키페어 생성 시 .ppk로 생성

xshell로 진행

연결 탭에서 호스트를 접속 할 퍼블릭 IP로 입력하고,

사용자 인증 탭에서 사용자 이름 (최초 접속 시 ec2-user) 입력 방법을 Password 클릭

분명 인증 방법으로 Password 방식을 선택했지만 key로만 접근이 가능한 상황.

우선 생성한 키 페어로 접속.

찾아보기 > 키 페어 선택 

암호는 입력하지 않아도 된다. ( ec2-user 접속 시 )

이제 password를 이용한 인증을 적용해 보자.

sudo vi /etc/ssh/sshd_config

PasswordAuthentication

no > yes 변경

sudo service sshd restart

sshd 재실행

sudo passwd ec2-user

ec2-user 패스워드 설정

설정한 패스워드 입력

AWS에서 EC2 검색

네트워크 및 보안 > 탄력적 IP

탄력적 IP 주소 할당

네트워크 경계 그룹 ap-northeast-2(서울)

탄력적 IP주소 할당 성공 화면

이전 게시물에서 복사한 test2 인스턴스에 할당

https://yes5.tistory.com/24

인스턴스 및 프라이빗 IP 주소 선택

EC2 인스턴스 목록에서

퍼블릭 IP, 탄력적 IP 할당된 모습 확인.

고정된 IP로 ssh 접속 확인.

탄력적 IP는 할당 받고 연결 하지 않으면 요금이 발생한다. 미사용시 삭제.

인스턴스 Name test로 진행

인스턴스 ID 클릭

작업 > 이미지 및 템플릿 > 이미지 생성

이미지 이름 : 알아보기 쉬운 이름으로 지정 예) 서버용도_날짜

이미지 설명 : 이미지에 대한 설명

재부팅 안 함 : 복제 시 재부팅 여부 결정, 서비스 중이라면 활성화를 하여 재부팅 방지

크기 : 복제 본의 용량 크기 설정 Gbyte 단위

종료시 삭제 : 종료 시 삭제 여부 결정

이미지 > AMI 이동

대기중 상태로 이미지가 생성된다.

이미지 크기가 클 수록 생성되는데 시간이 많이 소요된다.

이미지 > AMI 카탈로그에서 사용 가능한 퍼블릭 AMI 목록을 볼 수 있다.

이미지 상태가 사용 가능으로 변경 되면,

AMI ID 클릭 > AMI로 인스턴스 시작 

사용 할 서버 이름을 입력하고,

AMI는 자동으로 지정이 된다.

인스턴스 유형과 키 페어를 선택

putty를 ssh 클라이언트로 이용할 경우 .ppk

xshell 이용 시 .pem

네트워크 설정 (vpc, 서브넷, 보안그룹 등) 상황에 맞춰 설정

탄력적 IP를 사용할 예정이라 IP 자동할당을 비활성화 했다. 탄력적 IP 사용하지 않을 경우 활성화

https://yes5.tistory.com/25

test2 인스턴스 대기 중 상태 확인

잠시 기다리면 실행 중으로 변경된다.

zabbix version : 4.0.2

yum remove zabbix-agent -y

rpm -ivh http://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-agent-4.0.2-1.el7.x86_64.rpm

yum localinstall http://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-agent-4.0.2-1.el7.x86_64.rpm

vi /etc/zabbix/zabbix_agentd.conf

Server= zabix 서버 IP

Hostname=zabix 에이전트의 호스트 이름

예) WEB01

systemctl enable zabbix-agent.service

systemctl start zabbix-agent.service

Configuration > Hosts > 복사 할 정책 선택 > clone

Host name : zabix 에이전트의 호스트 이름

Groups : 적용할 그룹

IP address : IP 주소

입력 후 Add

보안

https

SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화

http

보안 기능을 제공하지 않음. 따라서 제3자가 데이터를 쉽게 볼 수 있다.

암호화

https

데이터를 암호화하여 도청이나 변조를 방지한다. 이로인해 웹사이트의 신뢰성과 보안을 높여준다.

http

암호화하지 않음. 따라서 데이터가 도청되거나 변조될 수 있다.

인증

https

SSL/TLS 인증서를 사용하여 클라이언트와 서버간의 인증을 수행한다. 

http

신원을 확인하지 않기 때문에 보안상의 위험이 있다.

1. jenkins 배포 중 No space left on device 발생

2.  /var/lib/docker/overlay2 용량 문제 확인

원인

/var/lib/docker/overlay2 가 용량이 큰 경우 diff/tmp 에 컨테이너 내부 파일구조 변경 사항들이 과도하게 쌓였기 때문.

1. Docker 컨테이너는 여러 레이어로 구성된 이미지를 기반으로 실행됩니다. 각 레이어는 독립적인 파일 시스템을 가지며, Docker는 이를 효율적으로 관리하기 위해 스토리지 드라이버를 사용합니다.
2. 이번 문제의 원인인 overlay2 드라이버는 Linux의 OverlayFS를 활용해 여러 디렉토리를 하나로 겹쳐 사용하는 유니온 파일 시스템입니다. 컨테이너 실행 중 기존 레이어에 변경 사항이 생기면, 해당 변경 사항만 새로운 레이어에 저장하는 Copy-on-Write(CoW) 전략을 사용하여 필요한 부분만 저장합니다. overlay2의 diff/tmp에 변경 사항이 과도하게 쌓이면 /var/lib/docker/overlay2 경로의 용량이 커질 수 있습니다.

해결

1. 미사용 이미지, 컨테이너, 볼륨 정리: docker system prune -a --volumes 명령어를 사용하면 중지된 컨테이너와 사용하지 않는 이미지, 네트워크, 볼륨을 안전하게 삭제할 수 있습니다.
2. 특정 이미지 또는 컨테이너 삭제: 더 이상 필요하지 않은 이미지나 컨테이너만 개별적으로 삭제할 수 있습니다 (docker rmi와 docker rm 명령어 사용).

이처럼 안전하게 정리할 수 있는 명령어로 overlay2의 공간을 확보하는 것이 좋습니다.