일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- docker
- VAGRANT
- devops
- cloud
- ECR
- CentOS
- Terraform Cloud
- vpc peering
- Clean Code
- cicd
- AWS
- IAM
- Python
- pro
- MIG
- gcp
- 우테캠
- IAP
- interconnect
- direnv
- Java
- vm
- cloud function
- k8s
- terraform
- snat
- Uptime Check
- pub/sub
- github
- kubernetes
- Today
- Total
목록AWS (10)
EMD Blog
OIDC란 Open ID Connect의 약자로 일종의 인증 프로토콜이다. 이와 관련된 문서들을 보면 매커니즘이 OAuth2.0과 매우 비슷하다는 느낌을 받을 수 있는데 이는 OIDC가 OAuth2.0을 기반으로 하기 때문이다. 자세한 설명은 아래 문서 참고. https://www.samsungsds.com/kr/insights/oidc.html Github Actions에서 AWS에 접근하고자 할 때 AWS인증과 권한을 필요로 한다. 예를 들면 파이프라인에서 S3에 파일을 업로드 할 때나 ECR Private Repository Push 할 때가 그렇다. 이때 Github Actions에서는 다음처럼 인증을 수행할 수 있다. (repository) - name: Configure AWS Credenti..
EKS 사용시 적용할 수 있는 권한체계는 2가지가 있다. 하나는 Cluster에 적용하는 리소스 기반 정책과 IAM Role Service Account(IRSA)를 사용해 Cluster 내 Service Account에 IAM Role을 연동하는 OIDC 방식이 존재한다. Cluster에 적용해서 AWS 리소스에 접근하든, Service Account로 접근하든 AWS 리소스에 액세스 하는 것은 마찬가지인데 왜 둘이 나눠져 있는 것인지 의문이 들어 확인해보고 정리한다. EKS cluster를 생성할 때, Cluster가 AWS에 액세스 할 수 있도록 Cluster에 role을 지정할 수 있다. 아래 문서를 보면 Cluster 생성 시 AmazonEKSClusterPolicy 정책이 포함된 role을 지..
Private하게 구성해놓은 RDS를 외부에서 접근하고 싶을 때가 있다. 다른 DBMS는 SSH 터널링 옵션을 사용해서 쉽게 붙을 수 있지만 SQL Server는 직접 터널을 열어줘야 한다고 한다. RDS 구성 RDS는 따로 구성이 필요하지는 않지만 외부 액세스 허용을 Off로 해주는 것과 Bastion host로 부터 접근 가능하도록 방화벽은 설정해주어야 한다. Bastion Host 구성 제일 최저 사양의 VM을 RDS와 같은 VPC에 생성한다. 이때 Bastion Host는 외부에서도 접근 가능해야하기 때문에 Public 서브넷에 구성해야하며 외부 IP를 부여해주어야 한다. module "ec2_instance_bastion" { source = "terraform-aws-modules/ec2-in..
Windows Server도 AWS Session Manager를 통해 연결 가능함. 사전 구성 https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager-prerequisites.html Windows Server 2012 ~ Windows Server 2019 (Session Manager는 2012 ~ 2019 버전만 지원함) SSM Agent 설치 아래 세 엔드포인트에 대한 443 아웃바운드 트래픽 허용 ec2messages.region.amazonaws.com ssm.region.amazonaws.com ssmmessages.region.amazonaws.com AWS CLI 1.16.12 버전 이상 설치 ..
로컬 개발 pc에 AWS account 설정 direnv 설정 aws key를 AWS_PROFILE 형태로 관리를 하면 한곳에서 AWS key를 관리할 수 있는 이점이 있고 사용시에도 편리하다. direnv 에서도 간단하게 사용할 AWS_PROFILE을 설정할 수 있다. .envrc 를 git에 올라가지 않도록 설정할 수 있기는 하지만 실수하면 올라갈 수 있는 위험이 있는데 AWS_PROFILE 형태로 하면 key가 노출될 위험이 줄어든다. $ cat ~/.aws/config [default] region=ap-northeast-2 output=text ….. [profile gw-dev] region=ap-northeast-2 $ cat ~/.aws/credentials ….. [ldy-dev] aws..
기존에 이미 AWS를 사용하기도 했었고 회사에서 자격증 취득을 지원해주는 것도 있기 때문에 공부겸해서 자격증을 따보기로 했다. 요즘에는 어떤 개발을 하더라도 퍼블릭 클라우드를 완전 배제하는 일은 별로 없기때문에 사람들이 가장 많이 따는 자격증 중 하나가 아닐까 싶다. 공부 기간: 12일 시험일 : 10월 28일 공부방법 친구한테 Udemy가 좋다는 말을 들어서 강의(이름만 강의고 모의시험)를 구매해서 공부했다. 총 6회의 모의시험이 있으며 하루는 문제풀고 하루는 해답보고하면 딱 12일동안 6회차를 전부 볼 수 있다. 나같은 경우는 이미 실무에서 좀 다양하게 AWS를 사용하고 있고 네트워크도 기초는 가지고 있는 상태에서 시작했기때문에 비교적 짧고 쉽게 시험을 치뤘지만 만약에 AWS 실무경험이 없거나 기초가..
CodeDeploy와 ELB를 활용해 Blue/Green 배포 중 헷갈리는 부분이 있었다. 기존에 알고있던 Blue/Green 배포 방식은 아래와 같았다. 부끄러운 일이지만 여태까지는 Blue/Green 배포가 이런 방식으로 진행되는 줄 알았다. 즉, AZ 단위로 하나씩 배포되는 방식인줄 알고 있었던 것이다. 더 부끄러운 것은 위 동작 방식은 동작 방식 그 자체도 Blue/Green 배포 방식이 아니다. 이렇게까지 잘못 이해하고 있었던 이유는 처음부터 배포단위를 착각했었던 이유가 제일 컸다. 그럼 AWS를 사용해 Blue/Green 배포에 대해 자세하게 살펴보자. 만약에 Blue/Green 배포가 무엇인지 모른다면 아래 글을 가볍게 읽고오자. https://www.redhat.com/ko/topics/d..
Jenkins를 설치했다면 파일을 주고 받기위해 RSA 암호화 키를 생성해야 한다. RSA Key를 생성하는 이유는 Jenkins에서 Git Repository에 접근할 때 Http가 아닌 SSH 방식으로 접근할 것이기 때문이다. 그럼 Key를 먼저 생성해보자. 생성하는 위치는 Jenkins가 설치되어 있는 서버 내 아무곳에나 생성하면 된다. $ ssh-keygen -t rsa -f study Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in study. 패스워드의 경우 일단 비워두고 진행하도록 하자. -t 암호화 형식이다. RSA를 사용할 것이므로 rsa로..
AWS를 사용하여 진행하며 요금이 과금될 수도 있습니다. 주의바랍니다. 꼭 AWS를 사용하지 않아도 다른 개인 서버(Local도 괜찮습니다.)를 사용해도 됩니다. Jenkins를 이용한 배포 자동화 이번에는 배포 자동화를 구현 해보자. 배포 자동화에 사용될 도구는 대표적인 CI 도구 중 하나인 Jenkins를 활용하도록 하겠다. 배포 프로세스는 이렇다. 먼저 개발을 하고 Commit 후 Github Repository의 Master로 Push를 하게 되면 Github에서는 WebHook을 통해 Jenkins에게 Push 이벤트를 보내고 Jenkins는 서버에 코드를 배포하게 된다. 서버는 AWS를 이용해서 진행하도록 하겠다. 먼저 Jenkins 서버로 사용할 EC2를 생성하자. 원래는 CentOS를 주로..
기존 구축되어 있던 환경을 Cloud로 Migration하는 것은 많은 생각을 하게 만든다. 특히 경험이 많은 시니어 개발자가 이끌어 주는, 혹은 이미 기존에 존재하던 대규모 시스템에 적용되어 있는 규칙을 따를 수 있는 상황이 아니라면 앞으로 구축할 인프라에 대한 걱정이 앞설 수 밖에 없다. 이제는 개발된 서비스의 방향성과 그에 따른 아키텍처, 인프라 구축에 대한 설계가 어느정도 끝이 나고있고 이제는 그에따라 구축만 하면되는 상황이지만 서비스 규모가 커지고, 개발자 인원이 늘어날 경우 리소스들이 스파게티 처럼 엉켜 처치불가한 상태가 될 수 있다. AWS에서는 이런 상황에 대한 다양한 해결법을 제시해 주고 있지만 우리는 먼저 가장 간단하게 바로 적용할 수 있는 리소스들의 Naming 규칙을 정해 도입해보는..