Infra 썸네일형 리스트형 Terraform 403 error 테라폼을 진행하기 위해서 terraform init terraform plan 위 과정을 진행 중에 403 에러가 뜨는 경우가 있다. terraform은 tf파일의 profile 정보에 맞는 .aws 폴더 credentials 파일의 계정 정보를 사용하는데, 해당 사용자에 특정 인프라 생성에 관한 권한이 없는 경우에 주로 발생한다. profile의 사용자에 terraform으로 생성하기 위한 적절한 권한을 부여해주면 해결된다. 더보기 AWS 정책 허용 여부 AWS IAM 정책의 허용 여부 결정 프로세스는 다음과 같다. 1. 명시적 거부 : 요청에 대한 모든 정책 문서에서 Deny를 탐색하고 존재할 시 무조건 거부 2. 명시적 허용 : 요청에 대해 Allow일 때 같은 요청에 대한 명시적 거부가 없다면 허용한다. 3. 묵시적 거부 : 명시되지 않은 항목에 대한 모든 요청은 기본적으로 거부된다. 위 번호 순서대로 우선순위를 가지게 되며 해당 우선순위는 IoT Core의 정책 등 다른 서비스에서도 동일하게 작동한다. IAM에선 한 그룹 혹은 사용자가 여러 정책을 attach할 수 있으며 IoT Core에서도 기기 그룹 혹은 기기가 여러 정책을 attach할 수 있기 때문에 서로 Allow-Deny로 상충되는 항목이 있다면 Deny가 우선된다는 것이다. 더보기 AWS Role-base Role base transfer 액세스 키, 시크릿 키를 활용하는 기존의 방법은 바람직하지 않음 *고객사에서 키를 제공하고자 하지 않으면 프로그램이 거의 돌아가지 않기 때문 Role base로 전환하여 진행하는 것이 바람직하다. Role base로 전향하기 위한 계획 Step 1. 권한이 필요한 기능들을 리스트업 한다. 2. 리스트업 한 항목들을 테스트한다. 3. 액세스 키를 제거한다. 4. 리스트업 항목들이 동작하지 않는지 점검한다. 5. 미리 작성해둔 최소권한 Role을 생성한다. 6. 해당 Role을 EC2에 적용한다. 7. 리스트업 항목들이 다시 동작하는지 점검한다. 권한 관련 테스트 리스트 프로젝트에 맞는 테스트 리스트 작성 자사 프로젝트 DDAP Role-base 테스트 Logstash가 s.. 더보기 내부 로드 밸런서란? Internal lb 인프라를 구성할 때 중요한 요소들 중 한가지인 로드 밸런서를 생성할 때의 첫 설정은 다음 이미지와 같다. 위의 설정들 외에도 수없이 많은 설정값들이 존재하며 굳이 건드릴 필요가 없는 설정들이 대부분이며 혹여나 문제가 있어도 후에 수정할 수 있는 설정이 대다수이다. 하지만 놀랍게도 설정의 가장 초반부에 돌이킬 수 없는 중요한 설정이 한가지 숨어있는데 바로 VPC선택 밑에 교묘하게 숨어있는 '내부 Load Balancer 생성'이다. 해당 설정은 말 그대로 로드 밸런서를 외부에서 바로 접근할 수 있는가에 대한 설정이다. 기본적으로 체크가 풀려있기에 사용에 지장이 없어서 신경쓰지 않는 경우가 생길 수 있으나 해당 설정을 미리 해놓지 않으면 외부에서 private subnet에 바로 접속할.. 더보기 AMI 생성 간 컨테이너 상태에 관한 이슈 Ami create issue 회사 프로젝트 인프라 구축 간 HA 구현을 위한 Auto scaling을 진행하기 위해 먼저 이중화에 대한 테스트를 진행하였다. 이중화 테스트를 위한 시작 템플릿을 작성하기 위해서는 AMI를 생성을 해야했고 필요한 모든 컨테이너를 띄운 상태에서 AMI를 생성해서 진행하였다. 문제점 하지만 AMI를 생성할 때 모든 컨테이너를 일괄적으로 중지시킨 상태로 생성한다는 점을 간과하였고 이 결과 템플릿을 활용하여 만든 사본 인스턴스의 컨테이너들은 원본 인스턴스의 환경변수 세팅이 되어있는 상태. 해결방안 AMI를 생성할 때 모든 컨테이너가 떠 있지 않은 상태로 생성하고 aws의 사용자 데이터 기능을 활용하여 새로운 인스턴스가 생성될 때 컨테이너를 띄워줌으로서 해결할 수 있다. 사용자 데.. 더보기 aws ec2 인스턴스 사용자 데이터 서버 이중화 및 Auto scaling 적용을 위해 원본 EC2 인스턴스의 AMI를 생성한다. 원본 인스턴스의 AMI를 이용하여 생성되는 사본 EC2 인스턴스의 경우 각 컨테이너의 환경변수(.env) 파일의 IPADDRESS 항목이 원본과 똑같이 지정되어있다. EUREKA_DEFAULT_ZONE의 경우 ELB의 DNS를 사용하기에 문제가 없으나 IPADDRESS의 경우 EC2 인스턴스 본인의 IP를 사용해야 하기에 이슈가 있다. EC2 인스턴스의 경우 사용자 데이터 라는 기능으로 인스턴스 실행 시 원하는 스크립트를 실행시킨 후 각 컨테이너를 띄울 수 있도록 부팅 옵션을 설정할 수 있다. 해당 설정의 경우 AMI를 생성할 때는 미리 지정할 수 없으며 시작 템플릿 생성 시 고급 세부 정보의 최하단에서 사용자.. 더보기 Ha multiplexing 다중화의 개요 다중화란 서비스의 가용성을 높이는 다양한 방법들 중 하나이다. 다중화 구성에는 다중화된 요소를 모두 이용할 수 있는 Active-Active와 다중화된 요소 중 일부는 사용할 수 없는 Active-Standby 두 종류가 있으며 Active-Standby는 Standby의 방식에 따라 다시 세 종류로 나뉜다. Hot Standby Standby 측은 가동 후 즉시 이용가능한 구성 Warm Standby Standby 측은 가동 후 이용가능하게 하기 위해서 준비가 필요한 구성 Cold Standby Standby 측을 정지시켜 두는 구성 기술적으로 가능하면 Active-Active가 가장 가용성이 좋다. 데이터를 저장하지 않은 Stateless 방식의 요소라면 Active-Active를 비교.. 더보기 HA of infra Infra ha 목차 0. 개요 1. 고가용성(HA)이란? 2. HA 구현시 예상 최소 사양 3. AWS가 제공하는 고가용성 4. Auto scaling 5. Elasticsearch clustering 6. 인프라 아키텍처 0. 개요 프로젝트 인프라 구축 간 High availability(이하 HA)의 중요성 대두 다중 AZ-다중 서버/단일 AZ-단일 서버/단일 AZ-다중 서버, active-active/active-standby 등 검토하여 적용이 필요하다는 결론 1. 고가용성(HA)이란? 고가용성이란 서버와 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 뜻하며 한마디로 '고장나지 않는 정도'. 고가용성은 흔히 가용한 시간의 비율을 99%, 99.. 더보기 이전 1 2 다음
