AWS-EC2-Root-volume-downsize-amazonlinux1-ext4

위에서 확장한 볼륨을 축소 할거다.

축소할 인스턴스의 OS 는 amazon linux 1 로 ext4 의 파일시스템을 가지고 있고 grub1을 사용한다. 따라서 아래 과정은 amazon linux 2 에 맞지 않는다.

볼륨 확장은 엄청 간단하다. 콘솔에서 늘리고 명령어 두줄이면 쨘!
근데..축소는? 축소는...?축소는!!!!!!! 간단하지 않다.

20G -> 5G 로 축소할거다. 가즈아!!!!!!!!!! 축소하기 위해선 먼저 준비물이 필요하다.

축소할 인스턴스의 루트 볼륨 스냅샷
위에서 만든 스냅샷으로 생성한 볼륨하나
루트볼륨을 복사할 볼륨
그리고 작업할 인스턴스. amazon linux 1

간략하게 설명하자면 현재 잘도는 인스턴스는 두고, 스냅샷으로 볼륨을 만들어서 다른 인스턴스에 연결한뒤에 거기서 축소...실은 복사 작업을 한뒤에 인스턴스 중지후 루트 볼륨 교체를 진행할거다. 그럼 볼륨을 먼저 생성하자.

볼륨은 이런식으로 xvdf(new) / xvdg(org) 로 연결한다. 작업할 인스턴스는 amazon linux 1이다.

Disk /dev/xvda: 15 GiB, 16106127360 bytes, 31457280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/xvda1 2048 31457246 31455199 15G 83 Linux

Disk /dev/xvdf: 5 GiB, 5368709120 bytes, 10485760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/xvfg: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ADC2A980-D341-46D7-9DA4-3652574FACDF
Device Start End Sectors Size Type
/dev/xvdg1 4096 41943006 41938911 20G Linux filesystem
/dev/xvdg2 2048 4095 2048 1M BIOS boot

세개의 파티션이 연결된걸 확인할수 있다.

작업전에 먼저 복사 대상 볼륨에서 파티션을 만들고 파일시스템을 생성해준다. 아래스크린샷은 이해를 돕기위해 찍은것이다.

# fdisk /dev/xvdf -> p (현재파티션확인) -> n(파티션생성) -> p(생성된 파티션확인) -> w(저장)

파티션을 만들었으면 linux dd 명령어로 복사해줘야한다.

아직 볼륨은 마운트하지 않은 상태에서 org 볼륨의 블럭사이즈를 확인해야 한다.

e2fsck -f /dev/xvdg1 명령어로 먼저 파일시스템을 체크한다.

[root@ip-172-31-12-119 mnt]# e2fsck -f /dev/xvdg1
e2fsck 1.43.5 (04-Aug-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/: 40330/1310720 files (0.1% non-contiguous), 392822/5242363 blocks

[root@ip-172-31-12-119 mnt]# resize2fs -M -p /dev/xvdg1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdg1 to 461003 (4k) blocks.
Begin pass 2 (max = 103395)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 160)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 4575)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/xvdg1 is now 461003 (4k) blocks long.

The filesystem on /dev/xvdg1 is now 461003 (4k) blocks long. 이부분에서 461003이게 현재 blockcount 다. 여기서 16MB 의 블럭사이즈를 계산해야 한다.

blockcount * 4 / (16 * 1024) 이렇게 계산해야 한다.

461003 * 4 / (16 * 1024) = 112.549560546875 로 계산되어 걍 올림해서 113이다. 이 16mb의 블록사이즈는 113개로...

dd bs=16M if=/dev/xvdg1 of=/dev/xvdf1 count=113 명령어로 블록단위 복사를 해줄거다.

[root@ip-172-31-12-119 mnt]# dd bs=16M if=/dev/xvdg1 of=/dev/xvdf1 count=113
113+0 records in
113+0 records out
1895825408 bytes (1.9 GB) copied, 29.3328 s, 64.6 MB/s
[root@ip-172-31-12-119 mnt]# resize2fs -p /dev/xvdf1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdf1 to 1310464 (4k) blocks.
The filesystem on /dev/xvdf1 is now 1310464 (4k) blocks long.

[root@ip-172-31-12-119 mnt]# resize2fs -p /dev/xvdf1
resize2fs 1.43.5 (04-Aug-2017)
Resizing the filesystem on /dev/xvdf1 to 1310464 (4k) blocks.
The filesystem on /dev/xvdf1 is now 1310464 (4k) blocks long.

[root@ip-172-31-12-119 mnt]# e2fsck -f /dev/xvdf1
e2fsck 1.43.5 (04-Aug-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/: 40330/327680 files (0.2% non-contiguous), 329605/1310464 blocks

정상적으로 복사가되면 resize2fs 와 e2fsck 가 먹는다. 그럼 이제 거의 다왔다.

마운트할 디렉토리를 생성한다.

# mkdir /mnt/new
# mkdir /mnt/org

파티션을 마운트한다.

# mount -t ext4 /dev/xvdf1 /mnt/new
# mount -t ext4 /dev/xvdg1 /mnt/org

마운트 확인한다.

df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 408K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/xvda1 15G 13G 2.3G 86% /
tmpfs 389M 0 389M 0% /run/user/1000
/dev/xvdf1 4.8G 20M 4.6G 1% /mnt/new
/dev/xvdg1 20G 1.3G 19G 7% /mnt/org

정상적으로 마운트가 됬다.

amazon linux 의 path는 uuid 가 아니라 label 기반이므로 그냥 복사한 파티션에 label 을 붙여 준다. 붙여 줄 라벨은 / 다.

# e2label /dev/xvdf1 /

라벨 지정이 완료 되었다면 blkid 를 이용해서 확인한다. 아래 화면은 이해를 돕기위한 내용이다.

# blkid
/dev/xvda1: LABEL="/" UUID="781f875d-4262-4f01-ba72-d6bd123785f5" TYPE="ext4"

그리고 grub install 을 해줘야한다.

먼저 마운트를 해줘야 한다.

#cd /mnt/new
# mount -B /dev dev
# mount -B /proc /proc
# mount -B /sys sys
# chroot .

제일 중요한 부분은 /proc 부분이다. mount bind 해주지 않으면 정상적으로 파티션 포지션을 불러오지 않는다.

chroot 까지 정상적으로 마쳐 지면 이제 거의 다왔다.
그냥은 안되고 몇가지를 수정해줘야 한다. 근래에 사용하는 aws 의 HOST가 변경되어서 볼륨 포지션이 좀 변경되었기 때문이다. amazon linux 1 에서는 /boot/grub/device.map의 수정이 필요하다. 하이퍼 바이저가 디바이스를 호출하는 이름이 변경된것이므로 수정하지 않으면 grub-install 이 불가능하다.

전) device.map 이 없을수도 있다. 없으면 걍 만들어 줘도 괜찮다.

#cat /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdf
(hd2) /dev/sdg

후)

#vi /boot/grub/device.map
(hd0) /dev/xdva
(hd1) /dev/xvdf
(hd2) /dev/xvfg
:wq!

변경을 완료하였다면 이제 grub-install 이 가능한 상태가 되었다.

# grub-install /dev/xvdf
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(hd0) /dev/xvda
(hd1) /dev/xvdf
(hd2) /dev/xvdg

이제 복구를 위해만든 인스턴스를 종료한다.

볼륨을 분리하면 정상적으로 분리가 된다. 이제 교체할 20G 볼륨인 인스턴스를 중지하고

원본 볼륨을 분리한다.

/dev/xvda 로 볼륨을 연결한다. 정상적으로 연결이 끝나면 인스턴스를 시작한다.

드디어 인스턴스가 떳다. 그럼 파티션을 확인해보자

[root@ip-172-31-43-226 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 4.9G 1.3G 3.6G 27% /

정상적으로 파티션이 보이면 축소가 완료된것이다.

OS마다 방법이 다르지만 centos6 amazonlinux1 / centos7 amazonlinux2 이렇게 동일할것이다. 참고하자.

읽어주셔서 감사하다!

좋은하루 되시라!

AWS-EC2-Root-Volume-Resize-Extending-linux

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

리눅스 볼륨 확장은 이 docs 를 참고하자. 먼저 오늘 테스트할 ami 는 amazon linux 1 이다.

[root@ip-172-31-43-226 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 7.9G 1.2G 6.6G 15% /

root 볼륨은 8G 로 1.2G를 사용중이다. 이걸 20G로 늘릴거다.

먼저 볼륨 태그를 잘확인한다.

amazon linux 1 은 ext4 에 /dev/xvda1 로 / 가 설정되고
amazon linux 2 는 xfs 에 /dev/nvme1n1p1 으로 / 가 설정 된다

확장 자체는 디바이스의 파티션을 지정해서 확장하므로 일반적으로 볼륨 하나당 하나의 파티션을 사용하는것을 권장한다. on-prem 처럼 하나의 볼륨에 여러개의 파티션을 사용한다면 확장은 힘들다.

볼륨수정을 눌러서 진행한다.

볼륨을 수정하면 optimizing 과정을 거쳐서 확장된다. 디스크를 사용중에도 확장할수 있으나, 안전한 작업을 위한다면 스냅샷을 생성하고 확장하자.

Disk /dev/xvda: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/xvda1 1 16777215 8388607+ ee GPT

/dev/xvda: 21.5 GB 볼륨이 확장된게 보인다.

현재 상태는 볼륨만 확장된것이고 파티션을 확장해야 한다.

# growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=16773086,end=16777182 new: size=41938910,end=41943006

amazon linux 1 의 경우엔 파티션이 xvda 로 보여서 xvda 의 첫번째 파티션은 1번을 확장한다.

amazon linux 2 의 경우엔 파티션이 nvme1n1p1 으로 보이므로 실제 명령어는

# growpart /dev/nvme1n1 1

로 명령어를 쳐야 한다. growpart 로 파티션을 확장하면 Disk label type: dos -> Disk label type: gpt 변경되고,

위처럼 디스크 라벨 부터 파티션 타입까지 변경된다.

fdisk -l 명령어로 확인하며 진행하자.

이제 다음은 파일시스템의 확장이 필요하다. 파일시스템 확장은 resize2fs 명령어로 확장한다.

# resize2fs /dev/xvda1
resize2fs 1.43.5 (04-Aug-2017)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 5242363 (4k) blocks long.

그럼 볼륨 확장이 완료된다.

볼륨확장에 대해 정리하자면 이렇다.

실제 볼륨을 확장하고 파티션을 확장하고 파일시스템을 확장한다.

# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 20G 1.3G 19G 7% /

정상적으로 확장된 파티션을 확인할수 있다.

xfs 에서 파티션 확장은 xfs_growfs 명령어를 사용한다. 참고하자.

AWS-VPC-Flowlog-Athena

VPC에서 아웃바운드로 향하는 모든포트를 확인해야하는 일이 생겼다.

그래서 이전 포스팅에서 먼저 과거의 방법을 이용해서 확인했고 이번에는 S3로 전송하여 보려한다.

아래는 이전의 방법으로 확인한 포스팅이다.

현재에는 이런 방법을 사용하지 않는다.

위에 작성한 방법은 ETL 과정을 거치는건데 사실 이렇게 할필요가 전혀없다.

https://docs.aws.amazon.com/ko_kr/athena/latest/ug/vpc-flow-logs.html

그냥 이거 따라하면 된다.

VPC-Flowlog 활성화 -S3 -athena

이렇게 간소화 되었다.

S3로 보내도록 로그를 생성한다.

S3 버킷 생성하는 부분은 생략한다.

CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
version int,
account string,
interfaceid string,
sourceaddress string,
destinationaddress string,
sourceport int,
destinationport int,
protocol int,
numpackets int,
numbytes bigint,
starttime int,
endtime int,
action string,
logstatus string
)
PARTITIONED BY (date date)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://your_log_bucket/prefix/AWSLogs/{subscribe_account_id}/vpcflowlogs/{region_code}/'
TBLPROPERTIES ("skip.header.line.count"="1");

명령어가 정상적으로 실행되면 위와같이 테이블을 확인할수있다

ALTER TABLE vpc_flow_logs
ADD PARTITION (date='2020-06-04')
location 's3://linuxer-blog-log/AWSLogs/328345415633/vpcflowlogs/ap-northeast-2/';

두줄을 적용하면 테이블이 등록된다. 유의할점이 지정한 날에 대한 단일 파티션만 생성된다.

이제 목적한 쿼리를 날려보자.

여기까지 테스트한이유는 아웃바운드의 모든 포트를 확인하기 위함이었다. 이제 쿼리를 해보자.

SELECT sourceport, count(*) cnt
FROM vpc_flow_logs
WHERE sourceaddress LIKE '10.0%'
GROUP BY sourceport
ORDER BY cnt desc
LIMIT 10;

이렇게 확인할수 있었다.

구 방법 부터 현재 권장하는 방법까지 테스트를 해보았고 같은결과를 확인하였다.

여기까지 읽어주셔서 감사하다!

-추가 쿼리

SELECT day_of_week(date) AS
day,
date,
interfaceid,
sourceaddress,
action,
protocol,
destinationaddress,
destinationport
FROM vpc_flow_logs_proc_20200702
WHERE action = 'REJECT' AND sourceaddress = '10.0.1.150'
LIMIT 1000;

AWS-VPC-flowlog-kinesis-Athena

아웃바운드로 연결되는 모든 포트를 확인하기위해 flowlog 를 이용해야 했다.

먼저 흐름을 그려보자.

https://aws.amazon.com/ko/blogs/big-data/analyzing-vpc-flow-logs-with-amazon-kinesis-firehose-amazon-athena-and-amazon-quicksight/

VPCflowlog enable -> cloudwatch loggroup -> lambda -> kinesis -> s3

이게 일단 저장하는 프로세스다.

지금은 좀더 간소화된 과정이 있으나 먼저 이전에 나온 방법을 학습하기 위해 이방법을 택했다.

먼저 저장 프로세스를 만들어보자.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/flow-logs.html

VPCflowlog 는 이런식으로 생성했다.

여기서 중요한것은 대상 로그 그룹이다. 역할은 자동생성 눌러서 그냥 만들어주자.

로그그룹은 따로 쌓기 위해서 새로만들어줬다.

로그그룹을 만들었다면 lambda를 생성하자. 람다는 어려울게 없다.

역할만 잘만들어주면 끝이다.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:::" }, { "Effect": "Allow", "Action": [ "firehose:PutRecordBatch" ], "Resource": [ "arn:aws:firehose::*:deliverystream/VPCFlowLogsDefaultToS3"
]
}
]
}

따로 역할을 생성할때 람다를 선택하거나 역할을 만들고 신뢰관계를 추가하자.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

람다를 생성하고 위의 역할을 생성해서 부여해 주자. python 2.7 을 사용했다.

아래 소스를 인라인에 붙여 넣자.

https://github.com/bsnively/aws-big-data-blog/blob/master/aws-blog-vpcflowlogs-athena-quicksight/CloudwatchLogsToFirehose/lambdacode.py

환경변수또한 잘 생성해 줘야 한다.

람다의 제한시간을 1분으로 해주자.

람다에서는 템플릿 변경할게없다.

람다를 정상적으로 생성했다면 CloudWatch Loggroup 에서 lamdba 에대해서 설정해 줄게 있다.

Create Lambda subscription filter 설정이다.

생성한 Lambda 로 지정해주면 된다.

그다음은 kinesis다.

kinesis 에서도 Kinesis Data Firehose delivery streams 를 설정해야 한다.

VPCFlowLogsDefaultToS3 이름은 람다에서 설정한 환경에 넣은 이름으로 한다.

설정해줄 부분은

역할 자동 생성.

S3 버킷 지정이랑 compession 을 gzip 으로 변경하자. 거의 다왔다. 여기까지 했으면 이제 ETL 설정은 끝이다.

Athena 서비스로 이동하자

Athena 에서 테이블을 생성해야 한다.

CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
Version INT,
Account STRING,
InterfaceId STRING,
SourceAddress STRING,
DestinationAddress STRING,
SourcePort INT,
DestinationPort INT,
Protocol INT,
Packets INT,
Bytes INT,
StartTime INT,
EndTime INT,
Action STRING,
LogStatus STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
"input.regex" = "^([^ ]+)\s+([0-9]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([^ ]+)\s+([0-9]+)\s+([0-9]+)\s+([^ ]+)\s+([^ ]+)$")
LOCATION 's3:///';

지금까지의 과정이 정상적으로 진행됬다면 이쿼리가 잘실행된이후에 테이블이 생성된다.

그리고 이제 포트를 확인하자 사용한 쿼리다.

SELECT sourceport, count(*) cnt
FROM vpc_flow_logs
WHERE sourceaddress LIKE '10.0%'
GROUP BY sourceport
ORDER BY cnt desc
LIMIT 10;

이런 내용이 나오고..

이렇게 VPC 에서 사용하는 sourceport 를 확인할 수 있다.

정리하자면 VPC IP가 sourceaddress 인경우에 port 를 count 한다 이다.

읽어주셔서 감사하다 !

linux-jaeger-setup

jaeger를 다운 받을 위치로 이동한다. 나는 amazon linux 2를 사용했고 일부패키지는 amazon-linux-extra 를 사용했다.

cd /usr/local/src/

위치에서 시작했다.

GOPATH=`pwd`
echo $GOPATH

gopath 를 설정했으면 gopath bin 을 path 로 지정해줘야 한다. 현재위치에서 gopath/bin 은 /usr/local/src/bin 이된다.

export PATH=$PATH:$GOPATH/bin

gopath bin을 설정해줬으면 사전 설치를 한다.

amazon-linux-extras install golang1.11
amazon-linux-extras install epel
curl -sL https://rpm.nodesource.com/setup_8.x | bash -
yum install -y git npm nodejs
npm install -g yarn
go get -u github.com/mjibson/esc
go get github.com/securego/gosec/cmd/gosec

nodejs가 8버전이 필요하다. go 1.11 버전이 최소 요구 버전이다.

이제 본격적인 설치를 시작한다.

git clone https://github.com/jaegertracing/jaeger.git jaeger
cd jaeger/

git clone 뜨고 디렉토리를 이동한다.

설치전에 CONTRIBUTING.md 파일을 꼭읽자.

https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING.md

git submodule update --init --recursive
make install-tools
make build-ui

여기까지 하면 설치가 완료된거다.

go run -tags ui ./cmd/all-in-one/main.go

명령어로 실행한다.

사이트 확인은 16686 포트이다

http://IP:16686/search

으로 접근해서 서비스를 확인하자.

이 화면이 뜨면 정상적으로 설치된거다.

읽어주셔서 감사하다.

jaeger 설치를 마친다.