resize

AWS-NCP-CDN-image-resize-AWS

AWS 에선 Lambda@Edge를 이용한 Image Resise를 할수 있습니다.

당근마켓-Lambda@Edge를 사용한 썸네일 생성

구성도는 위와 같습니다. 이걸 저도 다른 아키텍쳐로 구성한 경험이 있습니다.

따라하면 되는 부분을 빼버리고 좀 포인트가 필요한 부분만 정리를 하려 합니다.

Lambda는 이미 생성해둔 상태이고 역할도 부여해서 이제 Lambda@edge 로 배포하는 과정을 진행하는것입니다.

다음과 같은 메시지가 표시되면 배포가 시작된거라 생각하면 됩니다.

Designer에 위와 같이 trigger에 cloudfront 가 추가됩니다. 그럼 이 Lambda@edge는 CF의 Behaviors에서 확인할수 있습니다.

또한 CF의 Behaviors에 자동으로 추가가 된거까지 보이고, CF의 Status 가 Enabled 상태이면 각 엣지에 Lambda@edge가 정상적으로 배포되었다고 볼수있습니다.

원본이미지

https://linuxer.name/wp-content/uploads/2020/07/exam-az301-600x600-1.png

리사이즈 이미지

https://linuxer.name/wp-content/uploads/2020/07/exam-az301-600x600-1.png?w=200&h=150&f=webp&q=100

위와 같이 리사이즈된것을 확인할수 있습니다. URL 수정을 통해 리사이즈를 컨트롤 할수 있습니다

- w: '200'
- h: '150'
- f: 'webp'
- q: '90'

Cloud9을 이용하여 배포하고 수정하는 과정 자체가 불편하긴 하나, AWS의 인프라를 이용하여 serverless 환경에서 리사이즈 배포 저장공간 추가로 사용하지 않음 등의 잇점을 생각할때 매우 좋은 방법이라는 생각이 들었습니다.

이때 비용을 생각하지 않을수 없습니다.

REPORT RequestId: 9e879aa6-390e-432b-9baf-84f45b238a4b Duration: 1.88 ms Billed Duration: 50 ms Memory Size: 128 MB Max Memory Used: 107 MB

1회 실행한 로그이며, cloudwatch log group에서 확인할수 있었습니다. 계산은 제 블로그의 이미지 리퀘스트 횟수를 빗대어 계산해 보겠습니다.

All Requests: Total: 45.285 K

저는 Cloudfront 를 이용하여 Image를 제공하고 있고 월 평균 5만건 정도의 리퀘스트가 발생합니다.

1회요청당 0.0000006 USD * 50000 = 0.003 USD 입니다.

여기에 50ms 를 0.05 * 50000 = 2500 초를 실행한게 됩니다.

1초당 컴퓨팅 요금은 0.00000625125 USD입니다. 거기에 2500초를 곱합니다.

0.015628125 USD 입니다.

그럼 두가지 계산된 비용을 합칩니다.

0.018628125 USD가 한달 비용으로 발생하게 됩니다. 썼다면 너무 미미한 양이라 과금되는줄도 모르고 썼겠군요..또한 이건 단순계산으로 캐싱된것을 CDN에서 응답하면 람다 사용횟수가 80%는 줄어 들겁니다. HIT율이 80%는 되기 때문입니다.

한화로 환율을 계산하면 22원입니다. 계산이 무의미 하진 않지만..

정말 작은 돈으로 리사이즈를 할수 있다는것을 알수 있었습니다.

이 다음 포스팅은 NCP에서 image-resize를 사용해보고 비용계산을 진행해보려 합니다.

읽어주셔서 감사합니다.

2020년 7월 29일 by linuxer-admin AWS 0

AWS-EC2-Root-volume-downsize-amazonlinux2-xfs

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

작업의 흐름은 위 포스팅을 참고하기 바란다.

지금 포스팅은 xfs grug2 를 사용하는 사용자를 위한 포스팅이다.

amazon linux2 에 소스(xvdg)와 대상(xvdf)볼륨을 연결한다.

디렉토리를 생성하고

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

파티션을 생성하고

# fdisk /dev/nvme1n1

파일시스템을 생성하고

# mkfs.xfs -f /dev/nvme1n1p1

마운트한다

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

rsync 로 데이터를 복사해주고

# rsync -av /mnt/org/* /mnt/new

싱크가 끝나면 마운트한 경로로 이동한다.

# cd /mnt/new

그리고 blkid 를 이용하여 UUID 를 확인한다.

/dev/nvme1n1: PTUUID="9986d28e" PTTYPE="dos"
/dev/nvme1n1p1: LABEL="/" UUID="030df8fc-fb40-4ba6-af3e-662df2f52270" TYPE="xfs" PARTUUID="9986d28e-01"
/dev/nvme0n1: PTUUID="83181c97-6d5e-43c9-9ede-e2f50ead5338" PTTYPE="gpt"
/dev/nvme0n1p1: LABEL="/" UUID="55da5202-8008-43e8-8ade-2572319d9185" TYPE="xfs" PARTLABEL="Linux" PARTUUID="591e81f0-99a2-498d-93ec-c9ec776ecf42"
/dev/nvme0n1p128: PARTLABEL="BIOS Boot Partition" PARTUUID="4908ae49-9d5b-423e-a23c-a507a47bacf5"

일반적으론 UUID가 있을거지만.. 그경우엔 UUID 를 넣어주자.

# xfs_admin -U 'uuidgen' /dev/xvdf1

명령어로 UUID 생성해서 넣어줄수 있다. UUID 가 보인다면 new / org 변수에 UUID 를 export 해주자 UUID 는 사람마다 다들테니 각각 잘확인해서 복붙하자.

# export new=’3a26abfe-67eb-49e4-922a-73f6cd132402’
# export org=’781f875d-4262-4f01-ba72-d6bd123785f5’
# sed -i -e "s/$org/$new/g" etc/fstab
# sed -i -e "s/$org/$new/g" boot/grub2/grub.cfg
# mount -B /dev dev
# mount -B /proc /proc
# mount -B /sys sys
# chroot .

위 명령어를 치면 /mnt/new 경로에서 지정한 UUID 로 fstab 안의 UUID를 변경하고 grub.cfg 안의 UUID 또한 자동으로 치환해줄거다. 그런다음 3개의 경로를 bind mount 하고 현재위치에서 chroot . 를 치면 chroot 가 현재위치로 변경된다.

# grub2-install /dev/xvdf

chroot 가 정상적으로 먹는다면 볼륨을 변경하면 정상적으로 잘부팅된다.

테스트 해보고 꼭 작업하길 바란다.

수고하시라!

2020년 6월 23일 by linuxer-admin AWS Linux 4

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

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

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

축소할 인스턴스의 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 이렇게 동일할것이다. 참고하자.

읽어주셔서 감사하다!

좋은하루 되시라!

2020년 6월 23일 by linuxer-admin AWS Linux 0

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 명령어를 사용한다. 참고하자.

2020년 6월 23일 by linuxer-admin AWS Linux 0

GCP Cloud Functions

12월 29일 미션으로 Cloud Functions 이 포함되어있다.

미션은 이미지 업로드 후 리사이즈.

먼저 cloud functions 이 뭔지부터 알아야 한다. aws 에서 말하는 서버리스 컴퓨팅 서비스이다. 일반적으로 코어나 메모리를 정적으로 할당받아서 사용하는 방식이 아닌것이다.

먼저 Cloud Functions을 사용하기 위해서 진행해야 할 작업이 있다.

gcp의 큰장점을 cloudshell 을 지원한다는 것이다. 인스턴스쉘 이긴 하나 언제 어디서나 shell을 사용할수 있다.

먼저 cloudshell을 실행하면 이런 창이뜬다.

여기에 Cloud Functions 을 사용하기 위한 환경을 우선적으로 구성해야 한다.

먼저 cloudshell 은 굉장히 퓨어한 상태로 프로젝트부터 설정해줘야한다.

hoceneco@cloudshell:~$ gcloud config set project sage-facet-22972
Updated property [core/project].
hoceneco@cloudshell:~ (sage-facet-22972)

gcloud config set project 명령어로 지정하고

hoceneco@cloudshell:~ (sage-facet-22972)$ gcloud config list
[component_manager]
disable_update_check = True
[compute]
gce_metadata_read_timeout_sec = 5
[core]
account =
disable_usage_reporting = False
project = sage-facet-22972
[metrics]
environment = devshell

gcloud config list 명령어로 지정된 리스트를 확인할 수 있다.

hoceneco@cloudshell:~ (sage-facet-22972)$ sudo gcloud components update
Your current Cloud SDK version is: 274.0.0
You will be upgraded to version: 274.0.1
┌──────────────────────────────────────────────────┐
│ These components will be updated. │
├──────────────────────────┬────────────┬──────────┤
│ Name │ Version │ Size │
├──────────────────────────┼────────────┼──────────┤
│ Cloud SDK Core Libraries │ 2019.12.27 │ 12.7 MiB │
└──────────────────────────┴────────────┴──────────┘

gcloud 구성요소를 업데이트한다 - 꼭할필요는 없다.

오늘 미션에서 필요한 준비물은 Cloud Functions, Google Cloud Vision API, ImageMagick, Cloud Storage 이렇게 다.

hoceneco@cloudshell:~ (sage-facet-22972)$ gsutil mb gs://linuxer-upload
Creating gs://linuxer-upload/…
hoceneco@cloudshell:~ (sage-facet-22972)$ gsutil mb gs://linuxer-convert
Creating gs://linuxer-convert/…

linuxer-upload, linuxer-convert 버킷을 생성하고, 이름에 따라 업로드 와 리사이즈된 이미지를 넣을 버킷이다.

hoceneco@cloudshell:~ (sage-facet-229723)$ git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git
Cloning into 'nodejs-docs-samples'…
remote: Enumerating objects: 17312, done.
remote: Total 17312 (delta 0), reused 0 (delta 0), pack-reused 17312
Receiving objects: 100% (17312/17312), 15.29 MiB | 7.22 MiB/s, done.
Resolving deltas: 100% (11332/11332), done.
hoceneco@cloudshell:~ (sage-facet-229723)$ cd nodejs-docs-samples/functions/imagemagick

git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git
명령어를 이용하여 test code를 다운받고 다운받은 디렉토리로 이동한다.
일단 먼저 테스트하는것은 아래 Docs 를 참고하여 진행하였다.

https://cloud.google.com/functions/docs/tutorials/imagemagick?hl=ko

"버킷에 업로드되는 이미지 중 불쾌감을 주는 이미지를 감지하고 이를 흐리게 처리하는 방법을 설명합니다." 라고 한다.

hoceneco@cloudshell:~/nodejs-docs-samples/functions/imagemagick (sage-facet-22972)$ gcloud functions deploy blurOffensiveImages --trigger-bucket=gs://linuxer-upload --set-env-vars BLURRED_BUCKET_NAME=gs://linuxer-convert --runtime=nodejs8
Deploying function (may take a while - up to 2 minutes)…done.
availableMemoryMb: 256
entryPoint: blurOffensiveImages
environmentVariables:
BLURRED_BUCKET_NAME: gs://linuxer-convert
eventTrigger:
eventType: google.storage.object.finalize
failurePolicy: {}
resource: projects/_/buckets/linuxer-upload
service: storage.googleapis.com
labels:
deployment-tool: cli-gcloud
name: projects/sage-facet-22972/locations/us-central1/functions/blurOffensiveImages
runtime: nodejs8
serviceAccountEmail: sage-facet-229723@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/gcf-upload-us-central1-ede08b3c-b370-408b-ba59-95f296f42e3e/40187a52-802f-4924-98d1-8802e41b24da.zip?GoogleAccessId=service-300346160521@gcf-admin-robot.iam.gserviceaccount.com&Expires=1577509811&Signature=gUhzdRazlnkRrUgPmv2P3tjdw%2BtXTDZq1FDZtzchPBJjkn5trLN6c27mawLRneazA5%2FLFZuUCmBLXIb9%2B5Iaq2M6cM0c9kzCpKGrk41W%2Boh3ST4ybWHsxd1YZi9G4J0uCKCSs1aLw4WPcQ7nCRJhDv5pqBbXXIJUvFTkQqUzH98TnEx2o2u9aJd44iyrpWwEiirxG%2BxHk1sVBBKpdUAbJb%2FYOT0lzH6%2F7y%2FOP51A0kEcRtAbmPYHSt87%2FGZOrNn2qHdQWap4MiT%2BYd4eVLOLTkd%2Fmvv8%2FcjWS4cousamOq8FSvvDC%2BQmvf01AGOgt%2BBrHyDkmAlrLvzemw6989BFlA%3D%3D
status: ACTIVE
timeout: 60s
updateTime: '2019-12-28T04:40:54Z'
versionId: '1'

gcloud functions deploy 명령어로 functions 을 생성하면 된다. runtime 설정이 각각 사용하는 언어마다 다르므로 버전을 잘확인해보자.

생성이끝나면 명령어로 이미지를 업로드해본다.

hoceneco@cloudshell:~/nodejs-docs-samples/functions/imagemagick (sage-facet-22972)$ gsutil cp zombie-949916_1280.jpg gs://linuxer-upload
Copying file://zombie-949916_1280.jpg [Content-Type=image/jpeg]…
[1 files][355.3 KiB/355.3 KiB]
Operation completed over 1 objects/355.3 KiB.

이미지 업로드가 끝나면 functionc로그를 확인하면 정상작동됬는지 확인할수 있다.
첫번째 업로드에선 api 에러가 발생했는데. 이때 콘솔에서 api 를 사용할수 있도록 설정해줬다.

E blurOffensiveImages 909862418886020 2019-12-28 03:42:15.967 Error: 7 PERMISSION_DENIED: Cloud Vision API has not been used in project 300346160521 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/vision.googleapis.com/overview?project= then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
at Object.callErrorFromStatus (/srv/node_modules/@grpc/grpc-js/build/src/call.js:30:26)
at Http2CallStream.call.on (/srv/node_modules/@grpc/grpc-js/build/src/client.js:96:33)
at emitOne (events.js:121:20)
at Http2CallStream.emit (events.js:211:7)
at process.nextTick (/srv/node_modules/@grpc/grpc-js/build/src/call-stream.js:97:22)
at _combinedTickCallback (internal/process/next_tick.js:132:7)
at process._tickDomainCallback (internal/process/next_tick.js:219:9)
D blurOffensiveImages 909862418886020 2019-12-28 03:42:16.027 Function execution took 570 ms, finished with status: 'error'

https://console.developers.google.com/apis/api/vision.googleapis.com/overview?project=

링크를 눌러서 이동해서 사용하기 누르면 오래걸리지 않아 api 를 사용할수 있다.
그리고 이미지를 재업로드 하고 로그를 확인하면 다음과 같다.

hoceneco@cloudshell:~/nodejs-docs-samples/functions/imagemagick (sage-facet-229723)$ gcloud functions logs read --limit 100

D blurOffensiveImages 909862418886020 2019-12-28 03:42:16.027 Function execution took 570 ms, finished with status: 'error'
D blurOffensiveImages 909865384788642 2019-12-28 03:47:22.883 Function execution started
I blurOffensiveImages 909865384788642 2019-12-28 03:47:28.294 Analyzing zombie-949916_1280.jpg.
I blurOffensiveImages 909865384788642 2019-12-28 03:47:29.696 Detected zombie-949916_1280.jpg as inappropriate.
I blurOffensiveImages 909865384788642 2019-12-28 03:47:30.683 Downloaded zombie-949916_1280.jpg to /tmp/zombie-949916_1280.jpg.
I blurOffensiveImages 909865384788642 2019-12-28 03:47:40.091 Blurred image: zombie-949916_1280.jpg
I blurOffensiveImages 909865384788642 2019-12-28 03:47:40.414 Uploaded blurred image to: gs://gs://linuxer-convert/zombie-949916_1280.jpg
D blurOffensiveImages 909865384788642 2019-12-28 03:47:40.419 Function execution took 17551 ms, finished with status: 'ok'
D blurOffensiveImages 909860416701916 2019-12-28 03:51:04.290 Function execution started
I blurOffensiveImages 909860416701916 2019-12-28 03:51:04.295 Analyzing zombie-949916_1280.jpg.
I blurOffensiveImages 909860416701916 2019-12-28 03:51:05.663 Detected zombie-949916_1280.jpg as inappropriate.
I blurOffensiveImages 909860416701916 2019-12-28 03:51:06.283 Downloaded zombie-949916_1280.jpg to /tmp/zombie-949916_1280.jpg.

정상적으로 컨버팅이 된거다.

원본

블러처리된것.

자동으로 블러 처리가 완료된것을 확인할수 있다.

오늘의 미션은 resize이므로 resize를 하기위해선 index.js를 수정해야한다.
오늘의 실습에선 GraphicsMagick for node.js 을 이용해서 테스트를 진행했으므로 아주 수월했다. 원래사용한 blur 부분만 수정하면 될거 같았다.

https://aheckmann.github.io/gm/docs.html

blur
Accepts a radius and optional sigma (standard deviation).
gm("img.png").blur(radius [, sigma])

옵션은 위와 같고

resize
Resize the image.
options
%, @, !, < or > see the GraphicsMagick docs for details
gm("img.png").resize(width [, height [, options]])
To resize an image to a width of 40px while maintaining aspect ratio: gm("img.png").resize(40)
To resize an image to a height of 50px while maintaining aspect ratio: gm("img.png").resize(null, 50)
To resize an image to a fit a 40x50 rectangle while maintaining aspect ratio: gm("img.png").resize(40, 50)
To override the image's proportions and force a resize to 40x50: gm("img.png").resize(40, 50, "!")

그러니까

이부분을 .blur(0, 16) 부분을 resize 옵션으로 변경만 하면되는것이다.

.resize(200, 200) 으로 수정을 하였다.
그리고 functions deploy 하고

gcloud functions deploy blurOffensiveImages --runtime nodejs8 --trigger-bucket=gs://linuxer-upload --set-env-vars BLURRED_BUCKET_NAME=gs://linuxer-convert
Deploying function (may take a while - up to 2 minutes)…done.
availableMemoryMb: 256
entryPoint: blurOffensiveImages
environmentVariables:
BLURRED_BUCKET_NAME: gs://linuxer-convert
eventTrigger:
eventType: google.storage.object.finalize
failurePolicy: {}
resource: projects/_/buckets/linuxer-upload
service: storage.googleapis.com
labels:
deployment-tool: cli-gcloud
name: projects/sage-facet-22972/locations/us-central1/functions/blurOffensiveImages
runtime: nodejs8
serviceAccountEmail: sage-facet-22972@appspot.gserviceaccount.com
sourceUploadUrl: https://storage.googleapis.com/gcf-upload-us-central1-ede08b3c-b370-408b-ba59-95f296f2e3e/4a80effd-0371-4317-8651-0416cffc0563.zip?GoogleAccessId=service-300346160521@gcf-admin-robot.iam.gserviceaccount.com&Expires=1577519172&Signature=CrNrgjDfo8gsr%2FoeGkcEiRvnMskkK5J4JHRoDMyh9DpXnXmp4ivWOlRsQ136GL9iK4FBvsxmAtIby4WgTECry4dYU%2FN6UkfjZSBLVtzJnJxR%2F5h7ZLY9PMd%2BDYcV1AAVbw9i1paFgBNjAq1WhNiMmmXonFBpyRHBlqMLn4CKuW7QAmA7NXOugTpQY3b%2BQ9E1ia9uIZtNwqcKfv1C1GM8e2%2FdKhMwwlUPU2EYy9gb4nirHvsdrYbzdewabmPwlRtgq1b2wTjWiuMM53vO9fDy6skNaB58tqumSfUeHM%2FTrjQrlqGejjon2cx9IlH9xF5kGKfLGzBesXEHj%2B6K6ZqilA%3D%3D
status: ACTIVE
timeout: 60s
updateTime: '2019-12-28T07:17:00Z'
versionId: '5'

정상적으로 생성이 되면 업로드를 진행하였다.

D blurOffensiveImages 909966712855810 2019-12-28 07:17:16.904 Function execution started
I blurOffensiveImages 909966712855810 2019-12-28 07:17:17.003 Analyzing zombie-949916_1280.jpg.

functions 이 정상적으로 실행이 완료되고

이미지가 리사이즈 되는것을 확인할수 있었다.
355.3KB -> 12.69KB로 작아졌다. 물론이미지 사이즈도..

lamdba에 비해 사용이 너무편해서 깜짝놀랐다.

기능과 범위에 대해 알수있는 미션이었다. 유익함 별 다섯개.

2019년 12월 28일 by linuxer-admin GCP 0