천천히, 꾸준하게

Terraform Backend 사용하는 이유 협업 시에 리소스가 겹치거나 꼬이지 않게 Locking 하는 기능을 제공 로컬에 .tfstate 파일을 저장하여 관리하는 것보다 원격 저장소에 관리하는게 보안/관리적 측면에서 더 효과적임 생성된 리소스 자원(실제 상태)의 정보를 받아와 사용할 수 있음 코드로 보는 예제 기존 방식대로, 리소스를 개별 생성하고 output을 사용하지 않으면 생성된 리소스 자원을 하드 코딩하여 사용해야 함 기존 방식 resource "aws_instance" "example" { ami = data.aws_ami.amazon_linux_2.image_id instance_type = "t2.micro" availability_zone = "ap-northeast-2a" assoc..

Day 2 - VPC 프로비저닝 모듈을 사용하는 이유 캡슐화 재사용성 일관성 코드로 보는 예제 모듈을 사용하지 않으면, 각각의 개별 리소스들을 하나씩 생성해주고, 의존성을 확인해줘야 함. 모듈을 사용하면 모듈 내 변수에 값만 할당해주면 알아서 리소스들을 생성해줌 사용 예제를 보면 훨씬 간결하고 많은 공수 필요 없이 생성 가능 모듈을 사용하지 않았을 때 resource "aws_vpc" "main" { cidr_block = "192.168.0.0/22" instance_tenancy = "default" tags = { Name = "main" } } resource "aws_subnet" "public-2a" { vpc_id = aws_vpc.main.id cidr_block = "192.168.0.0..

Spring 코드를 작성하다가 JWT 토큰 혹은 암호화 키 값 등과 같이 코드 내에 중요 설정 값을 하드코딩되어 있는 것을 보고 보안 상 취약할 거 같아 관련 레퍼런스들을 찾아보니, AWS Parameter Store를 통해 키/값을 저장하고 코드 내에서 키를 통해 불러올 수 있는 것을 알아냈다. 하지만, 현재 필자는 Spring boot 2.7.0 버전을 사용하고 있는데 2.4.0 버전 이상부터 application 리소스 설정하는 방식이 바뀌어서 기존에 나와 있는 레퍼런스를 그대로 참고해서는 제대로 동작을 안 했다. 그래서 이번 기회에 최신 버전으로 동작하는 코드를 정리해보려고 한다. 추가로, 이번 기회에 Spring boot 2.4.0 이전 버전에서 파라미터 스토어를 사용하다가 2.4.0 버전 ..

Day 1 EC2 프로비저닝 (인스턴스 생성) 테라폼 문법 리소스 선언 “” “” "" "" { ami = "ami-123456" instance_type = "t2.micro" } resource "aws_instance" "db" { ami = "ami-123456" instance_type = "t2.micro" } ""은 소스 내에서 참조를 위해 사용하는 변수 Output 프로비저닝 된 리소스의 메타데이터를 가져옴 코드 내용 암시적(Implicit), 명시적(explicit) 종속성 암시적 종속성 (Implicit Dependency) EC2 인스턴스가 생성된 이후에 EIP가 생성되어 연결 됨 resource "aws_instance" "example_a" { ami = data.aws_ami.a..

이번 회사에서 AWS 및 테라폼 관련 교육을 진행하기 위해서 자료를 만들어보고자 작성하고 있다. 나도 아직 테라폼에 대해서는 잘 모르는 부분이 많기 때문에, 이번 기회를 통해서 학습 및 정리를 하려고 한다. 직접 AWS 콘솔에서 인프라 환경을 프로비저닝하고, 그 이후에 테라폼으로 작성하여 프로비저닝 하는 순서로 진행될 예정이다. 기본적으로, 이번 포스팅의 테라폼 환경 구성은 AWS 계정이 있는 것을 전제로 한다. Terraform 환경 구성 환경 구성에 필요한 건, Terraform과 AWS IAM이다. Terraform 설치 내가 처음에 테라폼을 사용했을 때는 정확하게는 잘 모르겠지만, 직접 Terraform을 설치하여 버전 관리가 조금 어려웠다. 근데 버전 관리를 쉽게 할수 있도록 tfenv를 지원하..

조금 늦은 감이 있지만, M1을 사용하면서 '어..? M1을 왜 그렇게나 좋다고들 하는 거지..?' 라고 생각이 많이 들었다. 다른 CPU와 벤치마킹을 한 통계를 봐도 M1 성능이 굉장히 좋다고들 하지만 실제로 체감되지는 않았었다. 그 이유는 내가 M1을 제대로 활용을 못한 탓이다. Apple Silicon을 지원하는 애플리케이션을 설치했어야 하는데, 생각을 못하고 Intel용 애플리케이션을 설치하고 사용하고 있었다. Intel용 애플리케이션도 돌아가더라 (with Rosetta) M1 이후에 굉장히 말이 많았었던건, 기존에 데스크탑용으로 나온 CPU들은 대부분 ARM 계열이 아닌, AMD 계열로 출시되어서 애플리케이션 호환에 대한 이슈가 굉장히 많을 것으로 예상했다. 이러한 호환성 문제를 해결하기 위해..

AWS는 서비스의 사용에 따라 다양한 종류로 나누어 자격증 시험을 제공한다. 그 중, AWS에서 배포 시스템을 설계하고 구현하는 능력을 검증하는 AWS Certified Solutions Architect - Associate(SAA-C02) 시험을 봤고, 어떻게 준비하고 공부했는지에 대해 공유하고자 후기를 남겨보고자 한다. 1. 시험 응시 자격 및 신청 AWS 모든 자격증 시험은 응시 자격이 필요 없다! 각각의 시험 카테고리마다 기초, Associate(어소시에이트), Professional(프로페서녈), Specialty(전문분야) 정도의 난이도를 부여 하는데 프로페셔널 시험을 보기 위해선 어소시에이트 자격이 있어야 하는건 아니다! 하지만, 시험에 합격하고 나면 다음 시험에 대해서 50% 할인 바우처..

서버를 운영할 때 예정된 시각에 맞춰 사용자의 원하는 명령이나 잡(job)을 수행해주는 cron은 정말 유용하게 사용될 수 있다. 하지만, 간혹 예기치 않게 수행되지 않거나, 우리가 원하는 동작으로 수행되지 않을 때가 있다. 이럴 경우에 미리 대비를 해놓지 않았다면, 편하게 지내려다가 낭패를 볼 수 있다. 때문에 이번 기회를 통해 정리하려고 한다. 0. cron 문법 cron은 문법을 갖추고 있다. 이 문법을 모른다면 사실 상 사용하기 어렵다. 하지만, 사용하다보면 모르기에도 어려운 문법 형태를 갖추고 있기 때문에 잘 기억을 해두었다가 다양한 형식으로 조정해보도록 하자. 시각을 표현하는 형태는 총 5개의 요소로 모두 띄어쓰기로 구분짓고 있다. 첫번째는 minute(분) —> 0~59 두번째는 hour(시..

EC2로 작업을 하다보면, 우리가 실제로 사용하는 시간과 아예 사용하지 않는 시간이 따로 나뉘어져 있다. 회사로 예를 들자면, 오전 9시부터 오후 6시와 같이 사무실에서 일하는 시간 외에는 전혀 EC2 인스턴스에 접근할 일이 없는 경우이다. (물론 야근이 없다면..😂) 따로 인스턴스를 중지 상태로 만들어주지 않는 이상 실행중이기 때문에 계속 초당 비용이 청구될 수 밖에 없어 굉장한 잉여 비용이다. 때문에, AWS Instance Scheduler를 설정해주어, 우리가 원하는 시간대에만 인스턴스를 실행 상태로, 그 외에 시간에는 인스턴스를 중지 상태로 만들어 비용 관리를 효율적으로할 수 있다. 사전 지식 및 작업 IAM IAM 설정은 꼭 사전에 습득하고 와야 해당 포스팅에 대해서 매끄럽게 진행이 가능하다..

example.com이라는 하나의 서비스 도메인을 가지고, 개발과 운영으로 분리된 AWS 계정에서 각각의 Route 53으로 도메인을 관리하기 위해서는 하위 도메인을 위임해야 한다. 이때, 필요한 것은 네임 서버 설정이다. 이를 통해 해당 도메인이 어떤 호스트 영역에서 관리되는지 확인이 가능하다. 하위 도메인 위임에 대해서, DNS 동작 원리와 연관 지어 알아보도록 하자. 도메인 규칙 필자는 이번 포스팅에서, 하나의 메인 도메인 southouse.com을 발급받았다고 가정하고 진행한다. 개발 환경은 *.dev.southouse.com이라는 규칙을 가지고 서비스에 따라 app.dev.southouse.com 등으로 지정하고, 이를 개발 도메인이라고 부르기로 했다. 운영 환경은 *.southouse.com이..