Browsing Tag

CloudNet@

AWS

[AWS] EKS Fargate Logging Setting – Sharing failure experiences

안녕하세요. ManVSCloud 김수현입니다.

09월 12일 AKOS(AWS Kubernetes Online Study)가 마무리되었습니다.
CloudNet@ 가시다님과 2021년도에 ANOS, DKOS, AKOS 총 3회의 스터디를 진행했습니다.

다시 한 번 가시다님에게 감사의 인사 올립니다.
이번 포스팅은 AKOS의 졸업 과제를 포스팅 해보았습니다.


Fargate logging

Fargate logging 설정을 해보았습니다.

우선 결과적으로는 실패했습니다.
아래 방식대로 진행하는데에 있어 로그를 중앙 집중화할 때 CloudWatch와 결합하여 사용할 AWS용 Fluent Bit에 대해 자세히 몰랐기 때문이라 해당 포스팅 이후 Fluent Bit에 대해 추가적인 공부를 한 뒤 성공시킬 것입니다.

우선 Fagate 프로필은 이미 생성된 상태로 진행했습니다.

먼저 로그 라우터를 구성하기 위해 아래 .yaml 파일을 생성하였습니다.

vi fp-demo.yaml

kind: Namespace
apiVersion: v1
metadata:
  name: fp-demo
  labels:
    aws-observability: enabled
(aks-user@myeks:default) [root@myeks-host ~]# kubectl apply -f fp-demo.yaml
namespace/fp-demo created
(aks-user@myeks:default) [root@myeks-host ~]# kubens fp-demo
Context "aks-user@myeks.ap-northeast-2.eksctl.io" modified.
Active namespace is "fp-demo".
(aks-user@myeks:fp-demo) [root@myeks-host ~]# 

cloudwatch_logs 플러그인을 사용하기 위해 아래와 같은 .yaml도 생성해주었습니다.

vi aws-logging-cloudwatch.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: aws-logging
  namespace: fp-demo
data:
  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match   *
        region ap-northeast-2
        log_group_name fluent-bit-cloudwatch
        log_stream_prefix from-fluent-bit-
        auto_create_group true

  parsers.conf: |
    [PARSER]
        Name crio
        Format Regex
        Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>P|F) (?<log>.*)$
        Time_Key    time
        Time_Format %Y-%m-%dT%H:%M:%S.%L%z

  filters.conf: |
     [FILTER]
        Name parser
        Match *
        Key_name log
        Parser crio
        Reserve_Data On
        Preserve_Key On

이 부분을 생성해줄 때 namespace 와 region 부분을 자신에게 맞게 설정하는 것이 중요합니다.

(aks-user@myeks:fp-demo) [root@myeks-host ~]# kubectl apply -f aws-logging-cloudwatch.yaml
configmap/aws-logging created

이후 CloudWatch IAM에 적용할 권한을 curl로 가져왔습니다.

(aks-user@myeks:fp-demo) [root@myeks-host ~]# curl -o permissions.json https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   215  100   215    0     0    637      0 --:--:-- --:--:-- --:--:--   636

위에서 받아온 파일을 이용하여 아래와 같이 정책을 생성하였습니다.

(aks-user@myeks:fp-demo) [root@myeks-host ~]# aws iam create-policy --policy-name eks-fargate-logging-policy --policy-document file://permissions.json

아래 명령어로 attach 해줍시다. 중요하게 넣어야할 부분은
“내 계정”, “위에서 생성한 정책”, “fagate role 이름” 정도인 것같습니다.

(aks-user@myeks:fp-demo) [root@myeks-host ~]# aws iam attach-role-policy \
>   --policy-arn arn:aws:iam::내계정:policy/eks-fargate-logging-policy \
>   --role-name 역할이름
내 계정
역할 이름

권한 부분을 마친 뒤 테스트를 위해 아래와 같이 pod를 하나 생성하였습니다.

nginx-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
  namespace: fp-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - name: http
              containerPort: 80
(aks-user@myeks:fp-demo) [root@myeks-host ~]# kubectl apply -f nginx-pod.yaml
deployment.apps/sample-app created

pod 생성 이후 아래 명령어로 logging 부분을 확인해보려 했으나 정상적으로 logging에 관련된 event가 발견되지 않았습니다.

(aks-user@myeks:fp-demo) [root@myeks-host ~]# kubectl get pod
NAME                             READY   STATUS    RESTARTS   AGE
kube-ops-view-5557846b44-ghhx7   1/1     Running   0          7m14s
sample-app-86b8cc866b-8njpn      1/1     Running   0          13m
sample-app-86b8cc866b-gz4x2      1/1     Running   0          13m
sample-app-86b8cc866b-l7gvb      1/1     Running   0          13m
(aks-user@myeks:fp-demo) [root@myeks-host ~]# 
(aks-user@myeks:fp-demo) [root@myeks-host ~]# kubectl describe pod sample-app-86b8cc866b-8njpn
Name:         sample-app-86b8cc866b-8njpn
Namespace:    fp-demo
Priority:     0
Node:         ip-192-168-2-43.ap-northeast-2.compute.internal/192.168.2.43
Start Time:   Sun, 19 Sep 2021 21:53:01 +0900
Labels:       app=nginx
              pod-template-hash=86b8cc866b
Annotations:  kubernetes.io/psp: eks.privileged
Status:       Running
IP:           192.168.2.137
IPs:
  IP:           192.168.2.137
Controlled By:  ReplicaSet/sample-app-86b8cc866b
Containers:
  nginx:
    Container ID:   docker://a5176ad1add9dcf2fd024e577f9c7e8af51c74d63f0c435c387220cce55ebada
    Image:          nginx:latest
    Image ID:       docker-pullable://nginx@sha256:853b221d3341add7aaadf5f81dd088ea943ab9c918766e295321294b035f3f3e
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 19 Sep 2021 21:53:05 +0900
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-mpdh4 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-mpdh4:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  13m   default-scheduler  Successfully assigned fp-demo/sample-app-86b8cc866b-8njpn to ip-192-168-2-43.ap-northeast-2.compute.internal
  Normal  Pulling    13m   kubelet            Pulling image "nginx:latest"
  Normal  Pulled     13m   kubelet            Successfully pulled image "nginx:latest" in 2.853770826s
  Normal  Created    13m   kubelet            Created container nginx
  Normal  Started    13m   kubelet            Started container nginx

이번 테스트는 실패했지만 추가적인 트러블 슈팅 이후 추가 포스팅 해보도록 하겠습니다.


Personal Comments

이번 졸업 과제는 바쁜 와중에 허겁지겁 하느라 고생을 한 것같습니다.
원래 다양한 주제를 고민했었는데 주말마저 당직이라 긴 시간을 투자하지 못해 아쉬움이 있습니다.

최근에 EKS Anywhere가 출시되어 이 부분을 졸업 과제로 해보는건 어떨까 생각했지만 VMware vSphere 사용하기도 애매하고 시간도 부족해 혹시라도 VMware vSphere를 사용하시는 분이 있다면 참고하여 테스트 해보시라고 아래에 링크를 남깁니다.

가시다님 한 해 스터디 준비하시느라 고생 많으셨습니다.
CloudNet@ 운영진분들에게 모두 감사의 인사드립니다.

긴 글 읽어주셔서 감사합니다.


Problems found

포스팅을 누르는 순간 실패한 원인을 찾은듯 합니다.

켜져있던 웹 창을 정리하던 중 helm chart 를 보자마자 뭔가 이상하다는 걸 알아챘습니다.
fagate logging인데 pod가 fagate로 동작하지 않는듯한?…

이후 포스팅은 이 부분을 해결하고 Fluent Bit에 대해 알아본 것을 공유하는 포스팅이 되겠네요.


IT/Linux/Kubernetes

[AKOS] Amazon EKS Study 시작

안녕하세요. ManVSCloud 김수현입니다.

오늘부터 CloudNet@에서 진행하는 AKOS(AWS Kubernetes Online Study)가 시작되었습니다. 2020년도는 Linuxer님, 2021년도는 가시다(Gasida)님과 함께하고 있습니다.

Kubernetes 스터디도 함께 했고 현재는 AWS의 EKS를 공부하고 있으며
Naver Cloud Platform의 NKS는 아마 따로 공부하게 될 것같습니다.


AWS Kubernetes Online Study

이전에 했던 DKOS(Docker Kubernetes Online Study)에 이어 AKOS(AWS Kubernetes Online Study)는 이제 배웠던 Kubernetes 과정을 이해한 뒤 AWS에서의 Kubernetes를 배워보는 시간이었습니다.

클러스터 구축
파드 생성 및 확인
RDS DB 확인

개인적으로 저는 이미 클라우드 환경에서는 AWS보다 Naver Cloud Platform을 이용해 Kubernetes를 먼저 사용해보았기 때문에 NKS가 조금 더 편하게 느껴졌습니다.

사용하기 편하고 쉬운건 Naver Cloud Platform의 NKS고 활용할 수 있는 범위는 넓은데 난이도가 높은 건 AWS의 EKS라고 해야하나? 개인적으로 그렇게 느껴졌습니다.

네이버 클라우드 플랫폼에서는 기본적으로 서비스를 만들 때 사용자가 편하게 사용할 수 있도록 배려하는 부분이 많다보니 아직 기능적인 부분에서는 다소 추가되어야할 부분이 있으나 추가된 이후가 기대되기는 합니다.


Personal Comments

끊임없이 공부하는 습관은 엔지니어에게 정말 좋은 습관이라고 생각합니다.
물론 부하가 생기지 않도록 컨디션 조절도 중요하지만요…

스케줄을 너무 가득 채워서 많은 것을 흡수 하려고 하면 오히려 번아웃이 한 번 찾아와 다시 시작하기가 너무 힘들더라구요.

오늘도 공부하는 엔지니어 분들 수고가 많으십니다.
과하게 하지말고 꾸준히 합시다.

긴 글 읽어주셔서 감사합니다.

IT/Linux/Kubernetes

YAML language 와 Kubernetes에서 요구되는 필드

안녕하세요. ManVSCloud 김수현입니다.

이번 주 일요일부터 Docker Kubernetes Online Study에서 Kubernetes 소개와 설치가 시작됩니다. 그러므로 오늘은 Yaml 파일에 대한 이해를 돕기 위해 노션에 정리해두었던 Yaml파일에 대한 내용을 정리하여 포스팅해보았습니다.


What is Yaml?

Yaml 또는 Yml 이란 사람이 쉽게 읽을 수 있는 형태로 표현된 데이터 직렬화 양식입니다.

데이터 직렬화는 메모리의 객체를 디스크에 저장하거나 통신하는 대상에게 올바른 형식으로 맞추어 전달하기 위해 바이트 스트림 형태로 만드는 것!
쉽게 말하자면 사람이 읽고 쓰기 쉽도록 만들어진 하나의 약속이라고 볼 수 있습니다.

쿠버네티스 매니페스트는 YAML과 JSON을 사용하게 되는데 주로 YAML을 이용하여 구성 파일을 작성하므로 YAML에 대해 알고 있으면 큰 도움이 됩니다.

  • 역직렬화 : 디스크에 저장된 데이터를 읽거나 네트워크를 통해 전송된 데이터를 받아 메모리에 재구축
  • 바이트 스트림 : 1 byte를 입출력 할 수 있는 스트림, JAVA에서 입출력 스트림을 통해 흘러가는 데이터의 기본 단위 (InputSteam과 OutputStream이 존재)
  • 스트림 : 데이터 처리연산을 지원하도록 소스에서 추출된 연속된 요소이며 데이터를 읽고 쓸 수 있도록 도와준다.
  • 매니페스트 : 컴퓨팅에서 집합의 일부 또는 논리정연한 단위인 파일들의 그룹을 위한 메타데이터를 포함하는 파일 (애플리케이션에 대한 필수적인 정보가 담겨있음)

Grammar

? Yaml 문법 포인트

  • Key: Value
  • mappings(해시 or 딕셔너리), sequences(배열 or 리스트), scalars(스트링 or 넘버 등)
  • 각 블록 부모-자식 관계는 들여쓰기로 구분
  • 를 이용하여 시퀀스 사용
  • # 는 주석
  • 는 문서의 시작 (스트림 시작)
  • 는 문서의 끝 (스트림 끝)
  • & 를 이용하여 anchor 설정 (정의)
  • * 를 이용하여 alias 설정 (참조)
  • 띄어쓰기

Scalars
integer: 100
string: “100” 또는 ‘100’
(“”는 이중 문자열, ”는 단일 문자열)
float: 100.0
boolean: yes

(yes/no, true/false, on/off)

→ Example
count: “1”
→ int가 아닌 string

size: ‘3.14’
→ float가 아닌 string

question: ture
→ boolean

answer: “true”
→ string

→ 추가 내용
◎ 값이 비어있으면 null (nil이 아님)
port: “80” 이라고 선언할 수 있으며 템플릿 엔진과 YAML Parser를 정상적으로 통과합니다. 하지만 쿠버네티스가 포트를 integer로 받아야할 경우 실패할 수 있습니다.
이때 YAML 노드 태그를 사용하여 특정 유형 추론을 강제화 할 수 있습니다.
port: !!int “80”
위와 같이 선언할 경우 port가 “”로 감싸져 있어도 int로 취급됩니다.
ex) age: !!str 21 (int가 아닌 string으로 강제)
◎ 추가적인 심화 내용은 아래
TIP의 YAML 기법 링크 참고


Sequences

→ Level 1

- one
- two
- three

Level 2

-
  - Lion
  - Tiger
  - Bear
-
  - Orange
  - Lemon
  - Pear

Level 3

-
  -
    - Golf
    - Soccer
    - Basketball

Mappings

Level 1

Language: English

Level 2

Language: English
  - A
  - B
  - C

Anchor & Alias

Level 1

Linux:
  - linux1: &linux1 centos
  - linux2: &linux2 ubuntu
  - linux3: &linux3 rocky
  - linux4: &linux4 suse

web_linux: *linux1
db_linux: *linux3

Level 2
(<< 를 이용하여 Override(자식 클래스에서 부모 클래스 재정의))

base: &default
  web: apache
  db: mysql
env:
  dev:
    <<: *default
    db: oracle

  prod:
    <<: *default
    web: nginx

⚠️ YAML 앵커 및 별칭은 ‘ [ ‘, ‘ ] ‘, ‘ { ‘, ‘ } ‘및 ‘ , ‘문자를 포함 할 수 없습니다.


Example

Kubernetes에서 퍼시스턴트볼륨을 생성하는 YAML 파일의 예시입니다.
(용량은 25GiB이며 ReadWriteOnce Mode로 생성)

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv0001
  labels:
    type: local
spec:
  capacity:
    storage: 25Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data/pv01"

In-depth course

CKAD 시험까지 생각하고 있다면 k8s의 yaml 파일 작성법까지 깊게 알아보는 것도 좋지않을까 생각합니다. 생성하고자 하는 쿠버네티스 오브젝트에 대한 YAML 파일 내에 필드 값들을 설정해주게 되는데 그 필드 값에 대한 내용을 알아보도록 하겠습니다.

  • apiVersion
    : 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지

종류
v1
: 쿠버네티스에서 발행한 첫 stable release API
(대부분의 api가 포함되어 있음)
apps/v1
: 쿠버네티스의 common API 모음, Deployment, RollingUpdate, ReplicaSet을 포함
batch/v1
: 배치 프로세스, job-like task를 위한 배포 api
autoscaling/v1
: pod의 autoscale 기능을 포함하는 API, 현재는 CPU metric을 사용한 scaling만 가능
(추후에 alpha, beta version에서 memory, custom metric으로 scaling 기능 추가예정)
batch/v1beta1
: batch/v1에서 cronJob으로 job을 돌리는 api가 추가
certivicates.k8s.io/v1 beta
: 클러스터의 secure network function들이 추가된 API
(TLS 등의 기능 추가)
extensions/v1beta
: Deployments, DaemonSets, ReplicatSets, Ingress 등 상당수 feature들이 새롭게 정의된 API 그러나 상당수의 api들이 apps/v1과 같은 그룹으로 이동되어서, 쿠버네티스 1.6버젼 이후부터는 deprecated 됨
policy/v1beta1
: pod에 대한 security rule이 정의된 API
rbac.authorization.k8s.io/v1
: 쿠버네티스의 role-based access control이 가능한 function이 정의됨

  • kind
    : 어떤 종류의 오브젝트를 생성하고자 하는지 (원하는 kind에 따라 apiVersion 종류가 달라짐)

종류
Pod
: pod을 정의하여 쿠버네티스 선언(아직 배포되지 않은 상태)
ReplicationController(or ReplicaSet)
: 쿠버네티스에 선언된 pod을 배포하기 위한 선언(replicas 갯수, readiness probe 등 선언)
Service
: 동적으로 생성된 pod(각각 다른 ip)을 라벨(label)과 라벨 셀렉터(label selector)을 사용하여 하나의 서비스로 묶어주는 역할
(ex. pod에 라벨이 “wonyoung”이 선언되어 있으면, service는 “wonyoung” label이 붙은 서비스만 골라내서 그 pod간에만 로드벨런싱을 동해 서비스를 외부에 제공)

  • metadata
    : 이름, 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분지어줄 데이터
  • spec
    : 오브젝트에 대해 어떤 상태를 의도하는지

? 생성 가능한 오브젝트에 대한 모든 spec 확인

? Pod에 대한 spec 포맷

? Deployment에 대한 spec 포맷


TIP

? YAML 기법
? YAML 유효성 검사
? YAML to JSON
? JSON to YAML

Personal Comments

YAML을 전혀 모르던 때에 띄어쓰기 조차 문법인지 몰라서 당황했던 기억이 있습니다.
이 포스팅을 통해 많은 분들이 YAML 문법이 무엇인지 그리고 Kubernetes를 시작하기 전 많은 도움이 되길 바랍니다.

긴 글 읽어주셔서 감사합니다.

IT/Linux/Kubernetes

Docker Kubernetes Online Study 스터디 시작! (Docker의 장점과 Network)

안녕하세요. ManVSCloud 김수현입니다.

CloudNet@에서 진행하는 DOCKER KUBERNETES ONLINE STUDY가 시작되었습니다.
1주차 Docker의 기초를 시작으로 Kubernetes를 제대로 배우게 되어 흥미롭습니다.

지금까지 Docker는 Docker-compose를 이용하여 임의적으로만 사용하거나 kubernetes도 wordpress 사이트를 올려본 것이 전부라 아직 미숙했는데 이번 기회에 깊이있게 공부하고 다양한 테스트를 시작할 수 있게 되었습니다.

오늘 스터디 이전에 정리해두었던 내용 중 몇가지를 포스팅하려 합니다.
Docker의 장점과 네트워크 관련 내용입니다.


Advantages of Docker

한국어 자막 지원합니다.

위 영상은 컨테이너가 무엇인지 알려주는 영상입니다.
한국어 자막도 지원하고 설명이 잘 되어있어 1분 30초만 투자하면 컨테이너가 무엇인지 알 수 있습니다.

도커의 장점 TOP 5
  • 신속한 애플리케이션 배포 – 컨테이너에는 애플리케이션 의 최소 런타임 요구 사항이 포함되어 크기를 줄이고 신속하게 배포 할 수 있습니다.
  • 머신 간 이식성 – 애플리케이션 및 모든 종속 항목을 Linux 커널, 플랫폼 배포 또는 배포 모델의 호스트 버전과 독립적인 단일 컨테이너로 번들링 할 수 있습니다. 또한 이 컨테이너는 Docker를 실행하는 다른 머신으로 전송할 수 있으며 호환성 문제없이 실행할 수 있습니다.
  • 버전 제어 및 구성 요소 재사용 – 컨테이너의 연속 버전을 추적하고 차이점을 검사하거나 이전 버전으로 롤백 할 수 있습니다. 또 컨테이너는 이전 레이어의 구성 요소를 재사용하므로 매우 가볍습니다.
  • 공유 – 원격 저장소를 사용하여 다른 사람과 컨테이너를 공유 할 수 있습니다. 
  • 가벼운 설치 공간 및 최소한의 오버 헤드 – Docker 이미지는 일반적으로 매우 작기 때문에 신속한 제공이 가능하고 새로운 애플리케이션 컨테이너를 배포하는 시간이 단축됩니다.
  • 단순화 된 유지 관리 – Docker는 애플리케이션 종속성으로 인한 노력과 문제의 위험을 줄여줍니다.

Network

root@dkos-master:~# ip route show
default via 192.168.0.1 dev enp0s3 proto static
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev enp0s3 proto kernel scope link src 192.168.0.30

제가 docker를 처음 사용했을 때 생겼던 궁금증이었는데 이제는 많은 블로그에 포스팅된 내용이기도 합니다.
docker 설치 및 실행 후 ip route show 또는 ip a 명령어로 확인 시 docker 0의 bridge 네트워크 IP 대역이 default 설정으로 172.17.0.0/16 대역으로 설정되어 있을 것입니다.
이 ip대역 변경이 가능합니다.

/etc/docker 디렉토리 아래 daemon.json라는 .json 파일이 없는데 이걸 만들어주면 됩니다.

root@dkos-master:~# vi /etc/docker/daemon.json

예를 들어 아래와 같은 대역대로 설정해주고 저장합니다.

{
"bip": "10.3.0.1/16"
}
root@dkos-master:~# systemctl restart docker

root@dkos-master:~# ip route show
default via 192.168.0.1 dev enp0s3 proto static
10.3.0.0/16 dev docker0 proto kernel scope link src 10.3.0.1 linkdown
192.168.0.0/24 dev enp0s3 proto kernel scope link src 192.168.0.30

root@dkos-master:~# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N DOCKER
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 10.3.0.0/16 ! -o docker0 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN

docker를 재시작해주면 설정해줬던 10.3.0.0/16 대역으로 변경된 것을 알 수 있습니다.

3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:2a:78:b0:a3 brd ff:ff:ff:ff:ff:ff
    inet 10.3.0.1/16 brd 10.3.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:2aff:fe78:b0a3/64 scope link
       valid_lft forever preferred_lft forever

브리지 네트워크 구성 방법에 대해 자세하게 알고싶으신 경우 아래 링크를 참고하시기 바랍니다.

또한 Docker에서는 다양한 네트워크 작동 방식이 존재합니다.
bridge, host, overlay, macvlan, none 등이 있는데 기본 네트워크 드라이브는 bridge로 설정되어 있으며 각 네트워크 작동 방식에 대해 설명하기에는 내용이 너무 방대하여 간단한 요약만 작성하겠습니다. 더 자세히 알고싶으신 경우 링크를 남겨두었으니 확인해보시기 바랍니다.

  • bridge : 동일한 Docker 호스트에서 통신하기 위해 여러 컨테이너가 필요할 때 사용
  • host : 네트워크 스택이 Docker 호스트에서 격리되어서는 안되지만 컨테이너의 다른 측면을 격리하려는 경우 사용
  • overlay : 통신을 위해 서로 다른 Docker 호스트에서 실행되는 컨테이너가 필요하거나 여러 애플리케이션이 스웜(swarm) 서비스를 사용하여 함께 작동 할 때 사용
  • macvlan : VM 설정에서 마이그레이션하거나 컨테이너가 각각 고유 한 MAC 주소를 가진 네트워크의 물리적 호스트처럼 보이도록해야 할 때 사용
  • ipvlan : ipvlan은 macvlan과 유사하지만 엔드포인트의 MAC 주소가 동일하며 L2 및 L3 모드를 지원합니다.
  • none : 모든 네트워킹을 비활성화, 스웜(swarm) 서비스 사용 불가

아래 링크는 Macvlan과 IPvlan의 차이점을 알 수 있습니다.


TIP

Docker는 단일 컨테이너 관리에 적합하도록 만들어져 있습니다.
컨테이너가 세분화되어 다수의 컨테이너화 된 앱을 사용하게 되면 관리와 오케스트레이션이 어려워집니다. 그렇다면 여기서 오케스트레이션은 무엇입니까?
오케스트라(orchestra)라는 말은 많이 들어보셨으리라 생각합니다.

오케스트레이션은 컴퓨팅, 네트워킹, 리소스 배포, 관리, 배치, 정렬을 자동화합니다.
위 컨테이너를 지휘하고 있는 이미지와 함께 보면 어떤 느낌인지 이해가 가시나요?
다수의 컨테이너가 네트워킹, 보안, 텔레메트리와 같은 서비스를 쉽게 제공하려면 이 컨테이너들을 그룹화해야 할 필요가 있습니다. 그렇기 때문에 Kubernetes, Docker Swarm, Apache Mesos, Nomad 와 같은 툴을 사용합니다.
Kubernetes는 무엇입니까? 컨테이너 오케스트레이션 툴입니다.


Personal Comments

이번 주 일요일부터는 Kubernetes에 대한 내용이 시작됩니다.
아직 화요일인데 벌써 일요일이 기다려지네요.
DKOS 스터디 진행 및 운영 해주시는 모든 운영진 분들에게 감사의 인사 올립니다.

마지막으로 컨테이너는 chroot와 namespace, cgroups과 같은 커널 기반 기술이 사용되는데 이에 대해 잘 설명이 되어있는 사이트가 있어 아래 링크로 공유합니다.

긴 글 읽어주셔서 감사합니다.

IT/Linux/Kubernetes

xcp-ng 8.2 install (xen server)

안녕하세요. ManVSCloud 김수현입니다.

오늘은 XenServer의 무료 버전인 XCP-ng 오픈소스 하이퍼바이저를 설치하도록 하겠습니다.
비유를 하지면 Xen이 Redhat, XCP-ng가 CentOS라고 보면 이해하기 쉬울 것입니다.

XCP-ng를 설치하는 이유는 곧 CloudNet@에서 진행하는 DKOS(Docker Kubernetes Online Study)를 실제 서버에 올려서 운영 테스트까지 하는 것이 목적이기 때문입니다.

서버 여러대 사용하는 것도 조금 아닌 것같고 그렇다고 약 8주간 스터디 동안 클라우드에 테스트용 서버를 계속 올렸다가 스냅샷찍고 내렸다가 반복하는 것도 아닌 것같아서 Xcp-ng를 설치하게 되었습니다.

알고계신가요? 네이버 클라우드도 XenServer으로 만들어졌다는 사실?
Xen Server와 가상화에 대한 개념이 궁금하신 분을 위해 아래 링크를 추가해두었습니다.


XCP-ng Install

XCP-ng는 위 링크에서 .iso파일을 다운로드할 수 있습니다.

설치 진행 시 첫 화면
키보드 레이아웃을 설정하는 곳입니다.
us로 선택하면 됩니다.
OS 설치가 진행되면 디스크에 기존 데이터들이 전부 삭제되니 백업을 하라는 내용입니다.
백업이 필요할 경우 Reboot 그냥 진행하려면 OK를 누르면 됩니다.
라이센스 동의하는지 묻는 내용입니다.
[Accept EULA]를 바로 선택해줍시다.
일반 서버에 설치하면 나오지않습니다.
일반 서버에 설치한 것은 화질이 좋지않아 제가 VirtualBox로 한번 더 이미지 뽑느라 나온 것!
VirtualBox에서 설치하면 가상화 지원에 이상이 있다고 알려주는 내용이니 무시합시다.
스토리지를 선택하는 곳입니다.
참고로 설치 시 최소 용량이 약 46G? 이상이 필요한 것으로 압니다.
일반 리눅스 설치할 때처럼 적게 용량을 주면 설치가 안될 것입니다.
설치한 .iso 파일을 마운트하여 설치하는 것이니 [Local media]를 선택하여 설치합니다.
위에서 선택한 media 설치 소스를 검증하기 위해 테스트할지 스킵할지 물어보는 것입니다.
Skip 해줍시다.
설치 후 XCP-ng Center의 초기 패스워드입니다.
계정은 root입니다.
네트워크 설정을 해줍시다.
DHCP를 체크 해제하고 Static configuration에서 고정 IP 설정이 가능합니다.
Host와 DNS 설정을 해주는 곳입니다.
위 이미지와 같이 원하는 host명과 DNS를 설정합니다.
Time Zone 설정하는 곳입니다.
[Asia]로 설정
[Seoul]을 선택합니다.
현지 시간 결정을 어떻게할지 물어봅니다.
NTP Server를 지정해줄 수 있습니다.
time.bora.net, time.nuri.net 등 공용 NTP 서버는 많으니 원하시는 NTP Server를 등록해주면 됩니다.
설정이 끝났습니다 Install 해줍시다.
이건 추가 패키지 설치할래? 물어보는 건데
추가 패키지 설치할 거 없으면 [No]를 선택하면 됩니다.
설치가 완료되면 위와 같은 화면을 볼 수 있습니다.
이 화면이 메인 화면인 Ctrl+Alt+F1 화면입니다.
Ctrl+Alt+F2는 시스템 메시지 화면이고 Ctrl+Alt+F3부터 아래와 같은 터미널 구경이 가능합니다.
Ctrl+Alt+F3
이건 제가 서버에 XCP-ng 설치 후 XCP-ng Center로 접속한 화면입니다. (XCP-ng-Center-20.04.00.32.msi)

XCP-ng Center는 아래 링크에서 다운로드 및 내용 확인이 가능합니다.


마무리

금일 저녁부터 DKOS가 시작됩니다.
스터디 이후에도 정기적으로 쿠버네티스 학습이 필요할 것으로 보입니다.
XCP-ng를 이용하여 쿠버네티스 Master,Node를 생성하고 각종 테스트 실습을 거칠 예정입니다.

집에 사용하지 않는 PC가 있다면 Xcp-ng를 설치하여 사용하면 생각보다 다양하게 사용할 수 있어 좋습니다.

긴 글 읽어주셔서 감사합니다.

IT/Linux/Kubernetes

Docker Kubernetes Online Study – Ubuntu 20.04 Install

안녕하세요. ManVSCloud 김수현입니다.

CloudNet@에서 진행했던 ANOS 2기 스터디에 이어 DKOS(DOCKER KUBERNETES ONLINE STUDY)의 기회를 얻게되었습니다.

핵심만 콕! 쿠버네티스

위 책을 기반으로 공부를 하게 될 것으로 보이며 스터디가 6월 6일부터 시작되어 Ubuntu 설치와 사전 권장 학습을 진행해야합니다.

오늘은 간단하게 Ubuntu 20.04 설치에 대해서 포스팅했습니다.


Ubuntu 20.04 Install

VirutalBox

VirutalBox는 위 링크에서 다운로드 받을 수 있으며 Ubuntu는 20.04 Server 버전으로 VirtualBox를 이용하여 설치해줄 것입니다.

일단 DKOS-Ubuntu-Master라는 이름으로 생성해주었습니다.
이후 Node를 OS부터 하나씩 설치하지않고 Master를 특정 부분까지 설치 및 설정 해준 뒤 스냅샷으로 Node를 생성할 것입니다.

English 선택
키보드 레이아웃 고르는 것입니다.
저는 Korean으로 선택해주었습니다.
네트워크 설정해주는 곳인데 저는 이곳에서 설정을 해줬습니다.
이후 서버 내에서 설정하는 것도 알려드리겠습니다.
DHCP로 하지않고 고정으로 설정 해보겠습니다.
저는 VirtualBox에서 네트워크 연결 방식을 “어댑터에 브릿지” 으로 설정해두었으므로
위와 같이 설정해주었습니다.
192.168.0.30을 Master IP로 사용할 것입니다.
이전에 CentOS 환경으로 Kubernetes를 설치 및 테스트한 경험이 있습니다.
이전에 테스트 당시 만들어둔 표인데 대충 참고만하면 좋을듯합니다.
Disk 파티션을 설정하는 곳입니다.
Custom storage layout을 선택하면 사용자 설정을 할 수 있지만 저는 그냥 통으로 설치했습니다.
사용자 계정과 패스워드 등을 설정해줍시다.
위 Install OpenSSH Server를 체크해줍시다.
이후 따로 설치해줄 필요없습니다.
설치가 진행되고 이후 update&reboot이 나오면 reboot을 진행해주고 설치를 마무리합니다.
설치가 완료되면 설치 시 생성한 사용자 계정을 통해 접속이 가능합니다.
설치가 완료되었다면 VirtualBox에서 스냅샷을 찍어줍시다.★
스냅샷을 찍어두는 습관은 이후에도 많은 도움이 됩니다.
putty를 이용하여 생성한 OS에 접근
Ubuntu 20.04 설치 완료

Today’s Tips

Ubuntu는 CentOS와 다른 것들이 많았습니다.
저도 Redhat 기반의 경험이 많아 데비안 환경은 조금 불편할 때가 많았습니다.

  • sudo
    (sudo su – 를 하여 root 계정으로 사용할 수 있지만 사용자 계정 환경에 익숙해져보려고 합니다.)
  • apt-get
    (CentOS에서는 패키지관리자가 yum으로 사용되었지만 Ubuntu에서는 apt-get으로 사용해줍니다. +rpm과 dpkg의 차이)

또한 Ubuntu18 이후 버전부터는 네트워크 설정 파일이 yaml 파일로 설정되어있습니다.
/etc/sysconfig/network-scripts/가 아닌 /etc/netplan/ 아래 yaml 파일을 이용하여 네트워크 설정이 가능합니다.

//편의를 위한 root 권한으로 변경
manvscloud@dkos-master:~$ sudo su -
[sudo] password for manvscloud:

//작업 전 백업
root@dkos-master:~# sudo cp -avp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml_org
'/etc/netplan/00-installer-config.yaml' -> '/etc/netplan/00-installer-config.yaml_org'
root@dkos-master:~# cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s3:
      addresses:
      - 192.168.0.30/24
      gateway4: 192.168.0.1
      nameservers:
        addresses:
        - 168.126.63.1
        search:
        - 169.126.63.2
  version: 2

위 yaml 파일을 보면 설치 시 설정했던 IP와 nameserver 등이 들어가있는 것을 볼 수 있습니다.
위 파일 수정 후 적용은 아래 명령어로 적용할 수 있습니다.

root@dkos-master:~# netplan apply

이후 스냅샷으로 생성한 Node들의 IP 설정을 해줄 때 사용하게 될 것입니다.
추가로 Hostname 변경 방법도 추가해두겠습니다.

//현재 hostname 확인
root@dkos-master:~# hostnamectl status

//hostname 변경
root@dkos-master:~# hostnamectl set-hostname dkos-node1

//hosts 파일 변경
root@dkos-master:~# vi /etc/hosts

network 및 hostname 설정간에 큰 어려움 없으시길 바랍니다.


Personal Comments

Kubernetes 시험 등록 후 다른 여러 일정으로 아직까지 시험을 못보고 있었습니다.
CloudNet@에서 진행하는 DKOS로 쿠버네티스 학습에 조금 더 집중을 할 수 있게 될 것같습니다. 2021-08-17 전에 시험 합격을 목표로 하고 있어 “네이버 클라우드에서의 보안” 포스팅을 제외하고는 쿠버네티스에 몰두할 예정입니다.

기회를 주신 CloudNet@ 팀에 다시 한 번 감사의 인사 올리며 포스팅을 마무리 하겠습니다.
긴 글 읽어주셔서 감사합니다.

AWS

AWS Network online study 11주차까지 마무리하며… [3/3]

안녕하세요. ManVSCloud 김수현입니다.

2021-01-10 ~ 2021-03-28 설 휴일을 제외한 약 11주차 과정이 마무리되었습니다.

생각보다 빠르게 11주차가 와서 아쉬우면서도 제가 11주차를 하루도 빠짐없이 다 해냈다는 것을 생각하면 또 한 편으로 보람차고 잘 했다는 생각이 들었습니다.

ANOS를 시작하기 전과 지금의 저를 비교해본다면 스스로가 Level UP 한 것같고 경험치를 상당히 얻은 기분입니다.
물론 ANOS를 마쳤다고 하여 AWS Network를 마무리할 생각은 없습니다.
아직 한 두번 해봤을 뿐 누군가에게 설명할 수 있을 정도는 아니기에 추가적인 복습을 통해 더 공부할 생각입니다.


가장 흥미로웠던 주제 3가지를 뽑자면?

  • CloudFront

물론 1주차부터 11주차까지 모두 재밌는 시간들이었지만 그 중에 굳이 3가지를 뽑자면Cloudfront와 WAF, TGW & R53 Resolver가 될 것같습니다. 특히 CloudFront의 경우 워낙 관심이 많았던 상태였기에 스터디가 마무리된 지금도 더 깊이 알고싶은 서비스 중에 하나입니다.

ANOS 스터디에서는 CloudFront에 대한 내용만 다룰 뿐만 아니라 CloudFront를 배우기 앞서 HTTP Cache와 CDN 기술에 대한 기본적인 지식까지 얻을 수 있으며 왜 CloudFront를 써야하는지 정확하게 알 수 있었던 시간이었습니다.

스터디를 시작하기 전에도 물론 제 블로그는 Cloudfront를 이용하여 정적이미지 파일들을 불러오고 있었지만 다소 정확히 알지 못하는 상태에서 사용 중이었고 Origin Shield가 없어 Hits율이 낮은 상태였습니다.

ANOS를 통해서 CloudFront를 정확히 이해하고 사용할 수 있게되었고 캐싱률도 상승하였으며 조금 더 깊이있게 공부하고 싶어질만큼 흥미로운 6주차 주제 CloudFront였습니다.

  • WAF 웹방화벽

두번째로 흥미로웠던 주제는 WAF입니다.
이 주제는 Legend 급으로 재밌었던… 8주차였습니다.

이 날 이후 제 블로그에는 AWS WAF 기능이 추가됩니다…?

제가 대학 전공을 보안학 전공을 하다보니 과거에 해킹과 보안에 관심이 많은 편이었습니다.
WAF를 배우며 오랜만에 공격 테스트도 해보고 방화벽을 통해 탐지/차단까지 실습해보니 재미가 없을 수가 없었습니다!

가끔 제가 설정해둔 WAF의 Sampled requests를 보는 편인데 생각보다 AnonymousIpList(익명 IP) 접속으로 차단되는 게 많은 편이었습니다.

이날 이후로 WAF 잘 쓰고 있어서 웹 공격으로부터 보안이 튼튼한 블로그가 된 것같아 기분이 좋네요.

  • TGW & R53 Resolver

마지막으로 TGW & R53 Resolver입니다. 특히 TGW!!

TGW는 해보면 와… 내가 정말 네트워크를 하고있구나라는 생각이 듭니다.

다소 난이도가 있으나 이거 하나 배워두면 아키텍처의 범위가 상당히 넓어지는 기분입니다.
아직 네트워크 쪽은 다양한 경험을 해보지 못했지만 지금까지의 제가 느낀바로 TGW는 AWS Network의 꽃이 아닐까…생각됩니다.

앞으로 TGW를 이용하여 리전 간 테스트를 종종 할 생각입니다.


ANOS 2기 MEMBER BLOG


마무리

11주라는 시간동안 고생해주신 CloudNet@ 팀, 운영진님들에게 다시 한 번 감사의 인사 드립니다. 아직 현업에서 아직 사용해보지 못한 기능들이 많았었는데 좋은 기회를 얻게 되어 다양한 서비스 실습을 할 수 있어 정말 많이 배웠습니다.

마지막 11주차까지 완주에 성공하신 ANOS 2기 멤버님들도 모두 축하드립니다.

다음 포스팅은 AI 전시회와 NCP DevOps, Kubernetes의 포스팅으로 찾아뵙겠습니다.
긴 글 읽어주셔서 감사합니다.

AWS

AWS NETWORK ONLINE STUDY 6-10주차 [2/3]

안녕하세요. ManVSCloud 김수현입니다.

벌써 3월이 마무리되어갑니다.
이번주 일요일은 AWS NETWORK ONLINE STUDY의 마지막 11주차 스터디가 있는 날입니다. 11주차라는 시간이 벌써 끝나간다는 아쉬움과 함께 하루도 빠짐없이 잘 해냈다는 보람도 있습니다.

오늘은 ANOS 6-10주차 후기 포스팅을 써보려합니다.
6-10주차는 크게 5가지 주제로 나뉘었습니다.

벌써 3월이 마무리되어갑니다.
이번주 일요일은 AWS NETWORK ONLINE STUDY의 마지막 11주차 스터디가 있는 날입니다. 11주차라는 시간이 벌써 끝나간다는 아쉬움과 함께 하루도 빠짐없이 잘 해냈다는 보람도 있습니다.

오늘은 ANOS 6-10주차 후기 포스팅을 써보려합니다.
6-10주차는 크게 5가지 주제로 나뉘었습니다.

# CloudFront
# Security Group & Network ACL
# WAF

# Global Accelerator & VPN
# TGW & R53 Resolver

이번 6-10 주차는 정말 1-5주차보다 더욱 알차고 배울 것이 많은 시간들을 보냈습니다.

CloudFront의 경우 CloudFront에 대해서만 배우는 것이 아니라 Cache에 대해서 배워 왜 CloudFront를 사용해야하고 정적 캐싱과 동적 캐싱에 대해서도 알아보는 시간을 가질 수 있었습니다.

제가 스터디 이후에도 CloudFront 스터디가 끝난 이후에도 해당 주제에 대해서는 추가적인 공부를 더 하였는데 블로그 포스팅으로 하려했으나 바쁜 일정에 아직도 임시글로 머물러있는 상태입니다…

Naver Cloud Platform DevOps 교육과 AI 전시회 참가로 인해 포스팅 거리가 최대 6개까지 늘어버렸군요…
최대한 시간나는대로 전부 포스팅할 예정입니다.

그리고 6-10주차 과정 중 가장 재밌었던 8주차의 WAF는 스터디에서 끝나지 않고 제 블로그에 도입되었습니다?!
아래 링크 참고하시면 WAF 기능 추가 내용 뿐만 아니라 제 블로그 구성도까지 볼 수 있습니다.

나머지 주차의 스터디도 전부 재밌었지만 이후 각각의 주제마다 느껴진 색다른 재미들이 있었다? 가 맞는 것같습니다.

스터디가 11주차까지 마무리되면 Global Accelerator & VPN과 TGW & R53 Resolver는 추가적인 복습을 할 예정입니다.
지금까지 제가 해본 적없던 것이기도 하고 아직 기초 네트워크에 대한 지식이 부족하여 조금 더 넓게 공부하고 싶은 생각이 있기때문입니다.

이번 ANOS를 통해서 매주 일요일마다 꾸준하게 공부할 수 있게 되었습니다.
이후 3기 참가하시는 분들에게 조언을 드리자면! 녹화보다는 생방송 참가 적극 권장드립니다.
일단 생방송으로 함께하는 것이 조금 더 집중에 도움되었습니다.

아마 이번 ANOS 스터디 일정이 마무리되면 NCP 시험과 계획되어 있던 Kubernetes의 CKA 자격증 공부에 집중하게 될 것같습니다.

밀린 포스팅을 업로드 한 뒤 Kubernetes의 내용이 다수 포스팅 될 예정입니다.
이만 글을 마무리하며 마지막 ANOS 11주차 포스팅으로 찾아뵙겠습니다.

CloudNet@ 팀에 다시 한 번 감사의 인사올리며
AWS NETWORK ONLINE STUDY 6-10주차 [2/3] 포스팅을 마무리 하도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.

AWS

AWS Network online study 1-5주차 [1/3]

안녕하세요. ManVSCloud 김수현입니다.

2020년 1월 23일 이후 Covid-19로 인해 많은 오프라인 문화가 사라지고 온라인 문화가 자리잡고 있습니다. 1년이 지난 지금까지 Covid-19 문제를 겪고 있는 현재 온라인으로 할 수 있는 것들이 더욱 발전할 전망입니다.

오늘은 제가 요즘 가장 즐겁게 활동하고 있는 온라인 스터디가 있어 스터디 후기를 써보려합니다.

CloudNet@ 에서 주최한 AWS NETWORK ONLINE STUDY(ANOS) 2기에 지원하여 AWS의 개인 역량을 키워가고 있습니다.
우선 긴 글을 이어가기 전에 이 스터디를 준비해주시고 기회를 주신 CloudNet@ 팀과 매끄러운 스터디 운영을 위해 도움주고 계시는 ANOS 매니저님들에게 감사의 인사 올립니다.

ANOS의 교과서는 “따라하며 배우는 AWS 네트워크 입문”이라는 서적입니다.
AWS에서의 네트워크를 알차게 배울 수 있을만큼 내용이 좋으며 이론 뿐만이 아니라 실습 과정이 있어 실제로 따라해보며 AWS 네트워크를 맛볼 수 있습니다.

ANOS에서는 위 서적의 내용뿐만 아니라 심화 과정까지 배울 수 있었습니다.
1~5주차에는 AWS Global Infra, VPC, VPCE, NAT, ELB, ROUTE53, VPC Peering을 공부했습니다.
AWS를 공부한지 이제 약 1년이 되었지만 레이턴시에 대해 깊게까지 생각해본 적도 없었으며 Cloud Formation은 사용할 이유가 없었기에 지금까지 사용해본 적이 없었기에 1주차 스터디의 내용부터 매우 흥미로웠습니다.

1주차 이후 레이턴시를 빠르게 확인할 수 있을만한 방법을 알아보았으며
2가지 사이트를 찾게되었습니다.

-. https://www.cloudping.info/
사용자의 브라우저에서 AWS의 각 리전까지의 레이턴시를 확인할 수 있는 사이트입니다.

-. https://www.cloudping.co/grid
각 리전 간 레이턴시를 확인할 수 있는 사이트입니다.

스터디 중 VPC, VPC Endpoint, NAT 등 실습 과정이 있었으며 AWS를 처음 접하시는 분들의 경우 리소스 삭제를 잊어 이상 요금이 발생하는 케이스가 있었습니다.
요금이 발생하는 것을 알림 받기위해 아래와 같은 과정을 추가 포스팅합니다.

CloudWatch+SNS를 이용하여 일정 이상의 요금이 발생하면 알림을 주도록 구성하는 방법입니다. CloudWatch에서 경보를 생성하고 SNS에 등록된 구독자에게 알림을 전송하는 방식입니다.

아래 CloudWatch 등록 전 위 결제 대시보드결제 기본 설정에서 결제 알람 받기를 클릭 후 저장합니다.

[CloudWatch]로 들어가서 <경보>에서 “결제”부분을 클릭합니다. (리전 : 버지니아 북부)
(결제 지표 데이터는 버지니아 북부에 저장됩니다.)

[경보 생성]을 클릭한 후 원하시는 기간, 요금 등을 원하시는 값에 맞게 변경해줍니다.

저의 경우 30USD 즉, 30달러 이상 비용이 발생하면 알람이 발생하여 제 이메일로 30달러 이상 비용이 발생했다고 알려주도록 설정해두었습니다.
평소에 테스트를 많이 하는 편이라 월 한화 2~3만원 사이로 비용이 발생하기때문입니다…

<알림> 부분에서 새 주제 또는 기존 SNS 주제를 선택하여 해당 알람을 수신할 주제를 선택해줍니다. 참고로 수신할 이메일을 새로 등록하셨다면 등록한 메일에 접속하여 구독 확인을 해주셔야합니다. “AWS Notification – Subscription Confirmation”라는 메일이 와있을 것입니다.

Q : 이메일이 아닌 SMS 문자로 받을 수는 없나요?
A : 현재 제가 아는 지식으로 위 방법만 이용하여 서울 리전에서 SMS 문자로 받는 방법은 없는 것으로 압니다.

도쿄 등 다른 리전에서는 SMS 문자로 받으실 수 있습니다.
SNS 구독 생성 시 프로토콜 부분에 문자를 지원하는 리전에서는 SMS 가 추가되어 있습니다.

현재 서울 리전에서는 SMS 문자를 받을 수 없다보니 많은 분들이 Telegram, Slack 등을 이용하여 모바일 알람을 받는 방법을 많이 해보신 것으로 압니다.

저 역시 Telegram을 이용하여 모바일 알람을 받으려고 생각한지 꽤 많은 시간이 지났으나 할 것이 너무 많아 아직 미뤄지고 있는 부분입니다?

이어서 ANOS 2기에서는 현업에서 일하고 있는 시스템/네트워크 엔지니어, 개발자, 보안 전문가 등이 모여 하는 스터디로 다양한 전문가분들과 교류할 수 있고 제 입장에서는 시스템 엔지니어로서 따로 시간내서 공부하지 않으면 배우지 못할 네트워크/개발/보안 부분의 지식을 더욱 얻어갈 수 있어 좋았습니다.

스터디 내용 중 어려운 부분이 있다면 역시 심화 과정 부분입니다.
저는 제 분야가 아님에도 심화 과정을 전부 참여하는 편입니다.
(물론 2월 8일 ~ 4월 2일까지는 야간 당직 기간이라 심화 과정을 못 듣게되는 날이 자주 있을 것 같습니다ㅠㅠ)
심화 과정의 내용은 상당히 깊이 있는 내용이 다루어지므로 난이도가 어렵습니다.
하지만 흥미롭고 조금 더 넓고 깊게 볼 수 있는 시야를 키우는 데에 좋은 영향을 주는 것같습니다. 심화 과정을 이해하기 위해서는 스터디가 끝나도 추가적인 학습이 필요했습니다.

오늘 5주차 ROUTE53 & VPC Peering을 마쳤습니다.

혼자서 공부한 AWS는 깊이가 있지않았고 늘 손대본 것들만 많았던 것같습니다.

1년이라는 시간동안 AWS를 공부했지만 한정적인 서비스와 기능만 사용했던 부분에 대해 반성하며 더욱 열심히 공부해야겠다는 생각이 들었습니다.

ANOS 3기는 대학생들을 대상으로 진행한다고 합니다.
많은 학생들이 이 스터디에 지원하여 도움이 되었으면 좋겠습니다.
코로나 때문에 하지못한 것이 아니라 코로나라서 무언가를 했다면 정말 보람있는 시간을 보냈을 것이라 생각됩니다.

ANOS 남은 6~11주차가 기대됩니다.

CloudNet@ 팀에 다시 한 번 감사의 인사올리며
AWS NETWORK ONLINE STUDY 1-5주차 [1/3] 포스팅을 마무리 하도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.