일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- aws
- linux 셸 스크립트
- github
- kubernetes
- Docker
- k8s chatops
- cloudfront s3
- github-actions
- kubenetes botkube
- markdown mermaid
- TLS
- nextjs html확장자
- k8s slack
- kubenetes slack
- ubuntu
- k8s botkube
- helm
- nextjs 정적배포
- k8s
- markdown
- botkube
- Diagrams
- SSH
- 리눅스
- Harbor
- linux 셸 프로그래밍
- Mermaid
- 쉘 프로그래밍
- terraform
- github actions
- Today
- Total
목록분류 전체보기 (59)
민한의 블로그
terraform 코드 (ex- main.tf) terraform 상태 (ex- terraform.tfstate) terraform 실제 원격지의 인프라 (ex- aws의 실제resource(s3, ec2 ... etc)) #terraform.tfstate ... "resources": [ { "mode": "managed", "type": "aws_instance", //여기 확인! "name": "web", //여기 확인! "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]", "instances": [ { "schema_version": 1, "attributes": { "ami": "ami-0b9954ae1a8f15194", "arn":..
terragrunt Quick start 요약 https://terragrunt.gruntwork.io/docs/getting-started/quick-start/ DRY는 Don't Repeat Yourself(자신을 반복하지 말 것)의 약자입니다. 간단히, Terragrunt는 Terraform에서 반복되는 폴더와 작업들을 줄이고자 사용하는 툴입니다. Terragrunt는 테라폼 코드를 DRY하고 유지보수가 편하게 만들어줍니다. PROD, QA, STAGE, DEV .. 몇개의 환경이 있던 상관없이 환경마다 중복되는 Provider, Backend, input variables 등을 Terragrunt로 한번만 정의해서 사용할수 있습니다. Terragrunt는 root 디렉터리에서 Terraf..
terraformer는 기존의 인프라를 terraform으로 관리하기 위해서 terraform import를 사용 하고자 하였으나, state만 가져오기에, 직접 tf파일을 작성하기에는 이건 좀 큰일이구나 싶을 때 찾아서 사용하였다. terraforming 이라는 AWS 전용 terraform import 도구가 있었는데 Project Status (2021-12-11): No longer actively maintained이라고 한다. 아무래도 멀티 클라우드 시대이니, 범용적으로 사용하기에도 좋고, 사용법도 편리한 terraformer를 선택하게 되었다. https://github.com/GoogleCloudPlatform/terraformer 이 주소로 들어가서 각자의 환경에 맞게 설치를 진행하면 되..
참고로 실습하기 편하기 위해서 간단하게 python으로 진행한것이였는데, 이럴바에 docker-compose로 하는 방법이 훨씬 속편하고 스트레스 안받았을것같다. 가능하다면 jupyter notebook을 설치해서 사용하는걸 권장한다. 예시로 맨 아래에 docker-compose 파일을 만들어놓았다. 가끔씩 내가 만든 인프라 구조를 다른 사람들에게 설명해주고 싶은데, 말로만 으로는 부족함을 많이 느껴서 다이어그램만드는 법을 많이 찾아보았다. https://www.diagrams.net/ 같은 툴이 있지만, 뭔가 나에게는 불편하고 조금은 부족하게 느껴졌었다. https://www.cloudcraft.co/ 솔직히 이것도 이쁜데.. 그러다가 찾은것이 https://diagrams.mingrammer.com/..
Dockerfile build를 하다가 RUN으로 폴더 이동하다가 원하는데로 작동을 하지 않을때 아래는 무슨짓을 써서라도 packages/app 폴더로 가서 작업을 하려고 한 의지가 보이는 Dockerfile이다. FROM node:16.13.2-alpine3.15 WORKDIR /usr/src/app COPY . . RUN pwd RUN ls -al RUN cd packages/app RUN pwd RUN ls -al RUN cd packages/app && ls -al && pwd RUN pwd ... 아래는 그 결과이다. Step 1/13 : FROM node:16.13.2-alpine3.15 16.13.2-alpine3.15: Pulling from library/node Status: Downl..
githubactions에서 dockerfile build 할떄 주의사항 github actions 에서의 step 작업은 항상 루트 파일로 이동한다. 따라서 각각의 스텝마다 작업을 할 공간으로 이동하거나, working-directory를 지정해주어야 한다. name: React CICD on: push: branches: ["develop"] jobs: working-directory-test: runs-on: ubuntu-18.04 env: working-directory: ./packages/app steps: - name: Checkout uses: actions/checkout@v3 - name: 'Create env file111' run: | pwd ls -al cd ./packages/a..
파드 라이프사이클 이해 애플리케이션을 종료하고 파드 재배치 예상하기 (어디로 갈까?) 실행중인 파드는 언제나 종료될수 있다. 기존의 환경에서는 실행중인 애플리케이션을 한 시스템에서 다른 시스템으로 이동 하는 경우가 드물지만, 쿠버네티스를 사용하면 더 자주 자동으로 이동, 배치된다. 쿠버네티스에서 기술적으로는 이전 파드를 대체하는 새로운 파드가 생성되는것이다. 스테이트리스(상태가 없는) 파드에 대해서는, 재배치 된것이 아니라, 새로운 IP, 이름, 호스트 이름을 갖는다. 스테이트풀(상태가 있는)인 스테이트풀셋은 새 노드로 재배치 되어도, 이전과 동일한 이름, 호스트 이름을 갖고, IP는 변경된다. - POD의 IP와 호스트 이름 변경이 되는것 확인 POD을 배치하고 삭제하는것을 확인해보자. kubectl ..
https://github.com/helm/helm/issues/1707 github actions에서 이미지 태그를 GITHUB_SHA 로 만든후 Helm value로 사용하려고 할때, 1465490을 태그로 넣었을 경우, 146549_e+06 이런 이상한수로 변경이 된다. 얘네는 왜 이걸 방치하고 있는것인지 모르겠는데. image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" 이렇게 되어있는 이미지를 image: "{{ .Values.image.repository }}:{{ int .Values.image.tag }}" 앞에 int를 넣어주면 해결된다. ---------------------------------------------------..
HTTP/HTTPS 이외에도 K8S등 에서도 사용이 많이 되어 한꺼번에 정리해보았다. 다만 내용이 다양하여, 자세한 내용은 출처로 들어가서 보는것이 좋다. HTTP https://korshika.tistory.com/142?category=974498 https://korshika.tistory.com/143?category=974498 HTTP는 무상태성(stateless), 비 연결성(connectionless) 프로토콜로 누가 요청을 했는지, 인증된 클라이언트인지 확인할수 없다. https://velog.io/@jakeseo_me/%EB%B2%88%EC%97%AD-passport-local%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EC%95%BC-%ED%9..
각각의 기능들에 대한 출처를 적어놓았습니다. 출처: https://jonnung.dev/posts/2021-01-28-aws-iam-role/ https://whchoi98.gitbook.io/aws-iam/iam-policy#iam 인증 : 로그인 인가 : 권한 확인 역할 (Roles) 정책 (Policies) 정책은 권한을 부여하는 방법이다. 하나 이상의 AWS 리소스에 대한 어떤 작업을 수행할 수 있는지 허용 규칙을 JSON 형식으로 작성된다. 이렇게 만들어진 정책이 IAM 사용자와 그룹, 역할에 연결된다. 그룹 (Groups) IAM 그룹은 다수의 IAM 사용자를 모아놓은 개념이다. 그룹이 필요한 이유는 IAM 사용자마다 매번 정책을 직접 연결해줘야 하는 번거로움과 관리 포인트를 줄일 수 있기 때..