시골쥐의 공부생활

IAM 이란?

AWS 자격 및 접근 관리(AWS Identity and Access Management, IAM)는 당신의 사용자들이 AWS 리소스에 대하여 가지는 접근 권한을 안전하게 제어할 수 있도록 도와주는 웹 서비스입니다. IAM을 사용하여 누가 AWS 리소스를 이용할 수 있는지(인증:Authentication), 그리고 사용자가 접근 가능한 리소스를 어떤 방식으로 이용할 수 있는지(권한 부여:Authorization)를 제어합니다.

* IAM 사용자 (User)

ROOT: aws 계정을 만들 때 사용한 전자메일 주소와 암호. aws 계정의 모든 리소스에 대한 무제한 접근 권한을 갖고 있음.

루트 사용자가 아닌 특정한 역할(role)을 가진 또는 그룹으로 묶어서 사용자를 지정하기 위한 용도

* IAM 역할(Role)

권한 정책이 부여된 자격(identity), 어떤 자격을 가졌을 때 aws 상에서 수행할 수 있는 작업의 범위.

ex. db를 쿼리한 다음 전자메일로 보내는 람다함수가 있는데, 실수로 db를 변경하지 않도록 읽기 쿼리만 실행할 수 있게 설정.

사용자와 차이점은, 역할은 자격증명(암호 또는 접근 키)를 갖지않음.

* IAM 정책(Policy)

'AWS 리소스'에서 수행할 수 있는 작업을 정의하는 규칙, 규칙들의 집합.

// 모든 S3에 모든 자격 부여

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }
}

// Hello-bucket이라는 버킷에서 오직 문자열 Bobs-로 시작하는 파일의 반환만 허용

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::Hello-bucket/*",
    "Condition": {"StringEquals": {"s3:prefix": "Bobs-"}}
}

출처:https://serverless-stack.com/chapters/ko/what-is-iam.html

https://dev.classmethod.jp/articles/what-is-aws-iam-kr/

https://blog.voidmainvoid.net/405

#docker 명령어 모음

https://www.daleseo.com/dockerfile/     // 다커 명령어 모음

# docker pull // docker-hub로부터 컨테이너 생성을 위한 이미지 가져오기

[ec2-user@ip-xxxx nodejs]$ docker pull python:3.9-slim

3.9-slim: Pulling from library/python

214ca5fb9032: Pull complete 

fa7d81b69b9a: Pull complete 

96a5a0a62ab5: Pull complete 

7d3628511179: Pull complete 

ea3879bc1c47: Pull complete 

Digest: sha256:364ada4cb4f943b603d330cbb3d26f689c8b54de51cb12bad1202de7dba31814

Status: Downloaded newer image for python:3.9-slim

docker.io/library/python:3.9-slim

// docker pull을 하면 하나의 파일이 다운되지 않고 여러 파일이 다운로드 된다.

docker는 레이어(layer)라는 것으로 이미지가 여러 개의 레이어가 되어있는데, 이게 다운로드 되는 것이다.

받아진 이미지를 분석해보고 싶다면 "docker inspect python:3.9-slim" 를 입력하면이 이미지 구성을 볼 수 있다.

[ec2-user@ip-xxxx nodejs]$ docker images

REPOSITORY   TAG        IMAGE ID       CREATED      SIZE

python       3.9-slim   29cc46b21611   5 days ago   125MB

[ec2-user@ip-xxxx nodejs]$ docker run -it --name=jane_python python:3.9-slim /bin/bash

root@c0b5a0c315fb:/# ls

bin  boot  dev etc  home  lib lib64  media  mnt  opt proc  root  run  sbin  srv  sys  tmp  usr  var

#docker_image삭제  // 삭제가 안될 때가 있음. 그럴 땐 container 확인

[ec2-user@ip-xxxx nodejs]$ docker rmi $(docker images -q). 

Error response from daemon: conflict: unable to delete 29cc46b21611 (must be forced) - image is being used by stopped container 7fabb7cdfd7a

#docker_container_조회

[ec2-user@ip-xxxx nodejs]$ docker container ls -a

CONTAINER ID   IMAGE             COMMAND     CREATED         STATUS                     PORTS     NAMES

7fabb7cdfd7a   python:3.9-slim   "python3"   4 minutes ago   Exited (0) 4 minutes ago             jane-test

#docker_container_삭제

[ec2-user@ip-xxxx nodejs]$ docker container rm 7fabb7cdfd7a 

7fabb7cdfd7a

[ec2-user@ip-xxxx nodejs]$ docker rmi 29cc46b21611

Untagged: python:3.9-slim

Untagged: python@sha256:364ada4cb4f943b603d330cbb3d26f689c8b54de51cb12bad1202de7dba31814

Deleted: sha256:29cc46b21611795a55a23f40290d9af983162d3d0a2cf4a11ab109a6c3183e06

#Dockerfile

[ec2-user@ip-xxxx nodejs]$ cat Dockerfile

FROM python:3.9-slim

WORKDIR /usr/src/app     // python 안에 있는 directory 

COPY . .

CMD ["test.py"]

[ec2-user@ip-xxxx nodejs]$ docker images

REPOSITORY   TAG       IMAGE ID   CREATED   SIZE

#docker_build

[ec2-user@ip-xxxx nodejs]$ docker build --tag jane-test .

Sending build context to Docker daemon  3.072kB

Step 1/4 : FROM python:3.9-slim

3.9-slim: Pulling from library/python

[root@ip-192-168-23-47 jane-test]# 

[ec2-user@ip-xxxx nodejs]$ docker images

REPOSITORY    TAG        IMAGE ID       CREATED         SIZE

jane-test   latest     7639b54570bf   2 seconds ago   125MB

python        3.9-slim   29cc46b21611   5 days ago      125MB

#docker_run

[ec2-user@ip-xxxx nodejs]$ docker run -it --name jane-test jane-test:latest

Hello World!

#docker_mount // Bind mounts를 이용해 호스트 파일 or 디렉토리를 컨테이너에 붙여 사용하기

[ec2-user@ip-xxxx nodejs]$ docker run -itd --name jane-test --mount type=bind,source="$(pwd)"/mount,target=/app ubuntu:18.04

Status: Downloaded newer image for ubuntu:18.04

d5c20934eb0f6a72286c24c5a092876bdd5064b84e5434031e29dc68a6657460

[ec2-user@ip-xxxx nodejs]$ docker ps

CONTAINER ID   IMAGE          COMMAND   CREATED         STATUS         PORTS     NAMES

d5c20934eb0f   ubuntu:18.04   "bash"    7 seconds ago   Up 6 seconds             jane-test

# 내부 디렉토리에 있는 게 컨테이너(위에서 target으로 삼은 경로)에도 동일하게 보임

[ec2-user@ip-xxxx nodejs]$ pwd

/home/ec2-user/jane-test/nodejs/mount

[ec2-user@ip-xxxx nodejs]$ ls

test.txt

[ec2-user@ip-xxxx nodejs]$ sudo docker exec -it jane-test ls /app

test.txt

Note) python 버전별 차이 (3.9-slim, buster …)

https://medium.com/swlh/alpine-slim-stretch-buster-jessie-bullseye-bookworm-what-are-the-differences-in-docker-62171ed4531d

nvm(node version manager): 여러 버전의 node.js 설치 및 전환 가능.

. LTS(Long Term Supported) 장기적 안정된 버전. 유지보수 목적의 사용자에게 추천. 짝수 버전 (ex. 8.x.x.)

. Current(현재 버전): 최신 기능 제공, 업데이트 잦고 기능 자주 변경. 개발/테스트에 적당. 홀수 버전 (ex. 9.x.x)

npm(node package manager): nodejs에서 사용되는 각종 코드 패키지 == 앱스토어st

. 설치여부, 버전 조회

$ node -v

  v8.9.4

$ npm -v

  5.6.0

. 패키지 매니저로 설치

. macOS - Homebrew (Homebrew: macOS용 패키지 관리자)

$ brew install node@8. // Major number만 입력

$ brew install nvm // nvm 설치

. NVM: node.js는 버전이 자주 바뀌어서 버전 관리 매니저 설치 필요.

$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash // NVM 설치

    . 설치 완료 후 ~/. bash_profile, ~/.zshrc, ~/.profile 에 nvm.sh이 실행되도록 아래 스크립트가 자동 추가됨.

       export NVM_DIR="$HOME/.nvm"

$ . ~/.nvm/nvm.sh // nvm 활성화

[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

$ nvm install 16.14.0 // 16.14.0 노드 설치 

$ node -v // 노드 버전 조회

$ npm init -y // default 값으로 설정된 package.json을 만듦 

(index.js가 만들면 js script가 들어오고. main으로 이걸 실행시키겠다. 라고 pakcage.json에 들어옴. )

. 원하는 nvm version 설치

$ nvm install <version> // nvm install 8.9.4

. 설치된 Node 버전 목록 확인

$ nvm ls

. 사용할 Node 설정

$ nvm use <version> // nvm use 8.9.4

$ nvm use <alias> // nvm use default

. package.json (프로젝트 정보와 의존성을 관리하는 문서)

어느 곳에서도 동일한 개발 환경을 구축할 수 있게 해줌. json format.

{

  "name": "project-name",

  "version": "1.0.0",

  "keywords": [], // npm search 사용 시 도움됨

  "description": "",   // 프로젝트 (패키지) 설명. npm search 시 도움됨

  "main": "index.js",  // 프로그램의 기본 진입 점(entry point)

  "scripts": {. // pkg 라아프 사이클에서 여러 번 실행되는 스크립트 명령. 

    "test": "echo \"Error: no test specified\" && exit 1"

  },

  "author": "HEROPY",

  "license": "MIT",

  "dependencies": {},       // 패키지 배포 시 포함될 의존성 모듈 지정

  "devDependencies": {}  // 개발 시 사용될 의존성 모듈 (배포 시는 포함되지 않음) 

  “files” // 패키지가 의존성으로 설치될 때 같이 포함된 파일들의 배열. 생략하면 모든 파일이 포함됨.

  “bugs”: { } // 패키지에 문제가 있을 때 보고될 이슈 트래커 및 이메일 주소 등에 대한 url

  “repository”: {} // 코드가 존재하는 장소. github 주소 지정 

} 

// package-lock.json: 개발 환경에서 내부 모듈 변경(ex. 버전)이 있을 경우, 

이를 방지하기 위해 package.json을 수정하는 모든 작업에 대해 package-lock.json이 자동으로 생성됨. 

. 의존성 모듈 설치

$ npm install <package>@<version>

. 전역으로 모듈 설치

$ npm install -g webpack  // -g 플래그

. 오래된 패키지 확인

$ npm outdated     // 설치된 패키지가 구형인지 확인하기 위해 레지스트리 검사

. 패키지를 최신 버전으로 업데이트

$ npm update <package>

$ npm upgrade   // pkg 입력하지 않으면 지정된 위치의 모든 패키지 업데이트

. 패키지 제거

 $ npm uninstall <pkg>

 $ npm remove

 $ npm unlink

. dockerfile

FROM node:12-alpine

WORKDIR /usr/src/app

MAINTAINER Jane Baek

RUN mkdir -p /usr/src/app

ADD . /usr/src/app

RUN npm install --silent

Gitlab에서 PR(Pull Request)이 있을 때마다 AWS의 API Gateway를 호출해서, Lambda까지 연동해본다.

(후속절차가 훨씬 많지만 이번 포스팅의 범위는 여기까지!)

0. 아키텍쳐

Gitlab (에서 이벤트 발생 시) -> API Gateway (호출) -> Lambda (호출) 

1. Lambda 생성

항상 이런 작업을 할 땐 가장 마지막 순서부터 하나씩 만들어놔야 하므로 Lambda를 먼저 생성한다.

event로 뭘 받아올지 궁금하니 event 부터 찍는 간단한 람다를 만들었다. (nodejs)

2. API Gateway에서 HTTP API 또는 REST API 생성

- 본인에 맞는 API를 생성한 후 필요한 리소스, 메소드를 설정, 이후 배포

   (나는 해당 api 호출 시 lambda를 trigger할 예정으로 Lambda함수를 선택해주었다.)

  * Lambda 프록시 통합 사용은, event를 받아올 때 요청 및 세부 정보들을 모두 lambda로 프록시한다고 한다. (옆에 i 누르면 설명 나옴)

- 스테이지 메뉴에 가면, URL이 나온다. 이 URL을 Gitlab의 Webhook 부분에 넣어주면 된다. -> 3번

메서드 요청, 메서드 응답은 API 프론트앤드(클라이언트) <-> API gateway간의 인터페이스이며 

통합 요청, 통합 응답은 API와 백엔드(본인의 경우 Lambda)간 인터페이스임.

클라이언트는 API를 사용해서 메서드 요청을 통해 백엔드 기능에 액세스 함. 

POST / 는 메서드 요청의 payload가 통합 요청의 페이로드와 같은 형식인 경우, 요청 payload를 수정 없이 통합 요청에 전달 가능.

GET / 은 통합 유형을 사용하며 실제 백엔드에 연동되지 않고 통합 요청을 설정하여 정적인 html을 반환함.

3. GitLab 설정

- Gitlab에서 본인이 사용하는 Repository settings에 접속하여 Webhooks 메뉴로 간다.

- 여기 URL에, 1에서 생성한 API의 URL을 복붙해준다. 

- 그리고 마지막, Active 설정.

Test connection을 눌러 ping을 날려보자.

굳

4. API 동작 확인 (Gitlab에서 Comment edited)

 - API가 잘 동작하는지 확인하기 위해, Gitlab의 Pull Request에서 (본인은 이미 있었음) Comment를 수정해본다.

     (위에서 Comment edited 조건 만들기)

 - Comment edited로 인해 API gateway가 호출되고, lambda까지 동작이 되었는지 로그를 확인한다.

   . 람다 >  모니터링 > Cloudwatch에서 로그보기

- 실행 되었다. 이제 event에 어떤 값들이 오는지 알았다.

+ JSON.stringify(event): event를 json format으로 예쁘게 다시 찍어보자

  // JSON.stringify: JavaScript 값이나 객체를 JSON 문자열로 변환

이제 이걸 사용해서 다른 동작들을 만들어보자.  to be continued...

EC2에서 s3에 업로드된 파일을 가져오고 싶을 때, 이렇게 하면 된다.

1. ec2에서 s3에 있는 파일 조회

$ aws s3 ls s3://[파일조회를 원하는 bucket명]

[ec2-user@ip-1-2-3-4 ~]$ aws s3 ls s3://test-bucket

2022-05-25 06:53:01   34174456 test.tar.gz

2. ec2에서 s3에 있는 파일 다운로드

$ aws s3 cp s3://[파일조회 원하는 bucket명]/[파일명] [복사를 원하는 디렉토리]

[ec2-user@ip-1-2-3-4 ~]$ aws s3 cp s3://test-bkt/test.tar.gz ./

download: s3://test-bkt/test.tar.gz to ./test.tar.gz

[ec2-user@ip-1-2-3-4~]$ ls

test.tar.gz

3. s3에서 ec2로 옮기고 싶은 경우는, 2와 반대로 하면된다.

$aws s3 cp [현재 복사 원하는 파일] s3://[업로드 원하는 bucket명]

[root@ip-1-2-3-4 ec2-user]# aws s3 cp test.sh s3://test-bkt

upload: ./test.sh to s3://test-bkt/test.sh       

4. move

는 cp부분만 바꿔서 하면 된다.

ec2를 pc에서 접속 시 public ip와 인증서(.pem)을 통해 ssh로 접속하는데, 접속이 안될 때가 있다.

(휴대폰 테더링을 통해 pc를 인터넷에 연결하면 그렇다.)

이 경우.. 아래와 같이 도메인으로 접속해보면 된다.

Before

ssh -i [인증서].pem -p [접속할 local port] ec2-user@[접속할 ec2의 public ip]

After

ssh -i [인증서].pem -p 20022 ec2-user@[접속할 ec2의 도메인 주소]

Download ZIP: 그냥 순수하게 파일들만 압축해서 다운로드 되어 집니다. 

Clone 주소복사: Clone은 순수파일들과 이 프로젝트의 커밋되었던 히스토리 정보까지 모두 다운로드가 되어 로컬저장소(Local Repository)를 만들어 줍니다. 

git Global Setup: config 설정 (누가 어떤 수정을 했는지 남기기 위해)

git config --list

를 쳐보자, Git에 설정에 대한 정보가 나온다. 이중에 꼭 설정해줄 내용은 사용자이름과 이메일!

git config --global user.name "user name"
git config --global user.email "이메일주소"

이 설정을 삭제하고 싶다면?

git config --unset user.name
git config --unset user.email

git clone (Create a new repository)

원격 저장소에 모든것을 로컬PC에 가져오기

(만들고자하는 경로에 이동하여 실행하면, 저장소이름과 같은 폴더가 만들어짐)

git clone <저장소 url> 

서버에서 파일을 Clone 하게 되면 내 컴퓨터의 지정된 폴더에 .git이라는 숨겨진 폴더가 생성되고 이 .git폴더를 가지고 있는 폴더가 작업 폴더(Working Directory)가 됩니다. 이 작업 폴더는 자동으로 서버와 링크가 맺어지게 됩니다.

이 .git폴더가 사실 로컬저장소의 역할을 하는 중요한 폴더로서 
서버와의 링크 정보와 변경된 히스토리 정보를 모두 가지고 있는 폴더 입니다. 
이 폴더를 사람이 수정하거나 추가/삭제를 할 필요가 없습니다. Git에서 알아서 운영합니다.

작업 폴더(Working Directory) 구성

작업폴더는 관리(추척)가 되는 파일과 관리(추적)되지 않는 파일로 나누어져 있습니다. 관리(추적)가 된다는 것은 이 파일의 생성, 수정, 삭제 등의 히스토리 정보를 모두 가지고 있다는 뜻입니다.

파일관리(추적)의 상태

추적은 바로 이전의 커밋을 깃점으로 아래의 4가지 상태로 관리됩니다.

• 추적안함 (Untracked) : 관리대상이 아님
• 추적함(Tracked)
  • 수정없음 (Unmodified) : 변경이 없는 파일
  • 수정함 (Modified) : 변경된 파일
  • 스테이지됨 (Staged) : 스태이지에 올라간 파일

git add

작업 폴더에 처음 파일을 생성한다면 이것은 아직 관리(추적)대상이 아닙니다. 관리대상이 아닐 경우는 아무런 히스토리 정보를 가지고 있지 않습니다. 이제 이 파일을 관리대상으로 삼기 위해서는 git add 명령어를 실행해 줘야 합니다. git add 명령어를 실행하면 이 파일이 스테이지(Staging Area) 로 올라가게 됩니다. 이제부터 이 파일의 수정, 삭제 등의 모든 정보는 Git에 기록이 되어집니다.

파일의 상태는 추적안함 (Untracked), 수정함 (Modified) 이 스테이지됨 (Staged) 으로 변경됩니다.

git add <파일 이름> // 특정 파일만 추가하기
git add . // 모든 파일을 추가하기

* 스테이지: 저장소에 커밋할 준비를 하기 위해 변경 내용을 임시로 저장할 위치

git commit

이제 스테이징된 파일들을 로컬 저장소(Local Repository)로 등록을 해야 합니다. 그러게 위해서는 git commit을 해야 합니다. git commit을 하면 현재 스태이징된 파일들을 그대로 스냅샷으로 찍어서 로컬 저장소(Local Repository)에 보관하게 됩니다. 이 스냅샷이 하나의 히스토리 기록이 되는 것입니다. 이 기록을 기준으로 과거로 되돌아갈 수도 있고 미래로 갈 수도 있고 다른 브랜치로도 이동할 수 있는 기준점이 됩니다.

파일의 상태는 스테이지됨 (Staged) 이 수정없음 (Unmodified) 으로 변경됩니다.

git commit -m "참고할 설명 작성"

git push

git commit으로 로컬 저장소(Local Repository)에 스냅샷을 찍어 이용하는 것은 내 컴퓨터에서만 가능한 상태입니다. 이것을 서버에 올려서 다른 사람들과 공유를 하기 위해서는 원격 저장소(Remote Repository)에 업로드를 해야 합니다.
그 명령어가 git push 입니다. git push를 하면 로컬 저장소의 커밋(git commit)된 모든 내용이 그대로 원격 저장소로 올라갑니다.

git pull

원격 저장소에 올라온 최신 수정본 파일을 내 로컬 저장소로 업데이트를 해야 할 필요가 있습니다. 그때 필요한 명령어가 git pull 입니다. 일단 한번은 서버와 링크가 맺어있어야 실행이 됩니다.

원격 저장소에서 로컬 저장소로 소스를 가져오는 명령어로는 pull과 fetch가 있습니다. 차이는 가져온 소스를 merge 하느냐 안하느냐의 차이가 있습니다. pull 명령어는 원격 저장소의 소스를 가져오고 해당 소스가 현재 내 소스보다 더 최신 버전이라고 하면 지금의 버전을 해당 소스에 맞춰 올립니다. merge 명령어를 사용하는 것이지요. 하지만 fetch의 경우 단지 소스를 가져올 뿐 merge 하지는 않습니다.

* Push an existing folder

이미 작업한 폴더, 이미 존재하는 폴더에 파일을 원격저장소에 올리기 (가장 많이쓰는 기능)

먼저 해당 폴더에 들어가서 remote 설정을 통해 원격저장소와 연결해야 합니다.

// git 작업을 위한 소스가 존재하는 폴더로 이동
cd 워킹디렉토리 안으로 이동

//.git 파일과 함께, Stage area, git 등의 구조가 만들어짐. 기존 디렉토리를 git으로 관리하겠다.
git init 

// 원격저장소 연결
git remote add [원격저장소 이름] git@[깃레포지토리 주소]
git remote add origin git@https://~
 
// 연결 설정 확인
git remote -v

// 폴더내 모든 파일 staging (.gitignore 파일을 참고하여 넘길파일 / 안 넘길파일을 결정)
git add .

// stage된 파일 commit으로 local git에 반영 (항상 커밋 메세지를 잘 써주세요) 
git commit -m "Initial commit"

// 연결된 원격저장소에 올리기
git push -u [원격 저장소 이름] [현재 브랜치명]
git push -u origin master

* -u 옵션: master라는 현재 브랜치를 자동으로 origin이라는 원격저장소의 master 브랜치로 연결해서

간단히 git push만 입력하여 반영하거나, git pull을 입력할 때 origin이라는 원격저장소의 master 브랜치를 

로컬저장소의 master브랜치로 merge할 수 있게 해주겠다는 의미. 앞으론 git push / git pull로 사용 가능.

$ git push

$ git pull

파일 상태를 짤막하게 확인하기

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

파일 무시하기

$ cat .gitignore
*.[oa]
*~

파일 삭제하기

$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

$ git rm --cached README

$ git rm log/\*.log

$ git rm \*~

출처

https://uxgjs.tistory.com/182

https://bangu4.tistory.com/102

https://ikcoo.tistory.com/44

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-git-push-u-%EC%98%B5%EC%85%98-%EC%9D%B4%EB%9E%80

https://sabarada.tistory.com/71?category=792135

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0

terraform을 설치할 때, 그냥 tfenv install 0.14.6 이렇게 설치하면 되지만,

m1에선 쉽게 되지 않는다.

이유 및 해결 방법

저 경로에 arm64가 없고 amd64가 있기 때문인데, 그럼 amd64를 wget을 통해 가져와준다.

# wget https://releases.hashicorp.com/terraform/0.14.6/terraform_0.14.6_darwin_amd64.zip

압축을 풀었고 terraform이 설치되었지만 여전히 버전 정보는 조회할 수 없다.

해결 방법

1) 위에서 요구하는 저 경로에( set by /opt/homebrew/Cellar/tfenv/2.2.3/version) vi version으로 0.14.6을 기입해주고,

test@HMH73K0H9Y 2.2.3 % ls

CHANGELOG.md LICENSE bin libexec version

INSTALL_RECEIPT.json README.md lib share versions

test@HMH73K0H9Y 2.2.3 % cat version

0.14.6

2) versions/ 뒤에 0.14.6 디렉토리를 만든 후,

test@HMH73K0H9Y bin % mkdir -p /opt/homebrew/Cellar/tfenv/2.2.3/versions/0.14.6/

3) 설치했었던 terraform 파일을 복사해준다.

test@HMH73K0H9Y bin % sudo mv ./terraform /opt/homebrew/Cellar/tfenv/2.2.3/versions/0.14.6/

해결 확인

test@HMH73K0H9Y 2.2.3 % tfenv use 0.14.6

Switching default version to v0.14.6

Switching completed

test@HMH73K0H9Y 2.2.3 % terraform --version

Terraform v0.14.6

Your version of Terraform is out of date! The latest version

is 1.2.0. You can update by downloading from https://www.terraform.io/downloads.html

- Hosting: 컨테이너(ECS, EKS)를 위한 컴퓨팅 리소스

  . EC2: 가상머신(VM) == 독립된 환경이 있고 운영체제를 갖고 있는 컴퓨팅 리소스

  . Fargate: EC2보다 더 추상화된 컴퓨팅 환경. 기본 인프라 관리할 필요 없는 EC2의 서버리스 버전. 앱별 자동으로 리소스 지정.

- Management(ECS, EKS): 

 . ECS(Elastic Container Service): 컨테이너 기반의 컴퓨팅 플랫폼. 단순함. AWS에서만 제공되는 Orchestration. AWS Only

 . EKS(Elastic Kubernetes Service): 컨테이너 기반의 k8s 환경 플랫폼. 보다 복잡함. K8s 환경이라 플랫폼간 이전 용이(범용)

  * 차이점

   1) LB(Load Balancing): ECS는 앞단 LB에서만 로드를 분산시키지만, EKS는 K8s 내부 proxy가 있어 pod간 노드 분산도 가능함.

 2) Networking(IP할당): ECS는 task별 ENI(Elastic Network I/F)를 할당받지만, EKS는 단일 pod마다 IP 할당받을 수 있음.

      ECS는 pod를 15개까지 만들 수 있는 반면, EKS는 750개 까지 만들 수 있음. 그래서 큰 서비스를 만들 거라면 EKS가 나음.

 3) Pricing(비용): 클러스터는 ECS는 무료지만 EKS는 시간당 0.20 USD(한달이면 144 USD).

      나머지는 사용하는 리소스에 따라 각기 부과됨. 

출처: 

https://timewizhan.tistory.com/entry/AWS-ECS-vs-EKS

https://ondemand.tistory.com/354​

1. JSON.parse와 JSON.stringify 차이

 - JSON.parse: JSON 텍스트 문자열을 JavaScript 객체로 변환

 - JSON.stringify: js스크립트 객체를 JSON 텍스트로 변환하고 해당 JSON 텍스트를 문자열에 저장
 - toString(): 문자열로 변환

 - JSON.parse: JSON 형태의 객체로 변환

- JSON.stringify: JSON 형태의 문자열(string)로 변환

구문: JSON.stringify(value[, replacer[, space]])

 . value: JSON 문자열로 변환할 값.

 . replacer: json 문자열에 포함되어야 하는 객체의 속성. null or 제공되지 않으면, 객체의 모든 속성들이 포함됨.

                   (array 방식이면 array만 포함됨)

 . space: 가독성을 목적으로 문자열 출력에 공백을 삽입하는 객체 (=공백으로 사용되는 스페이스 수. \t도 사용됨.)

- 실습: s3에 저장된 json 파일을 하나 불러와서 JSON.parse, JSON.stringfy, string 형태로 각각 변환 후 출력.

- JSON_parse: 그 자체로 객체로 출력된다.

- JSON_stringify: JSON 형태의 문자열로 출력한다

- tostring: 전체를 문자열로 출력한다.