전체 글

Packer가 설치가 되면 이제 이미지를 빌드를 할 수 있다. 튜토리얼에서는 t2.micro Amazon EC2 AMI를 빌드를 한다. Packer Template 사용 Packer Template이란 빌드할 이미지와 빌드 방법을 정의하는 구성 파일이다. 이 파일 내부는 HashiCorp사에서 만든 HCL이란 언어를 사용한다. 먼저 packer_tutorial 이라는 이름의 새로운 디렉터리를 만들고 이 디렉토리 Packer Template 튜토리얼에 대한 내용이 들어간다. cd ~ mkdir packer_tutorial cd packer_tutorial 생성한 디렉토리로 이동하여 aws-ubuntu.pkr.hcl 파일을 만든 후 해당 블럭을 내용에 추가한다. packer { required_plugins..

먼저 Packer를 설치부터 진행하려고 한다. 설치에 대한 문서는 Link를 확인해 보면 설치에 대한 방법을 볼 수 있다. 나는 AWS 머신 이미지를 만들기 위해서 AWS의 Amazon Linux 2 를 사용하여 돈을 최대한 안나오게 사용을 하려 한다. 여기서는 Amazon Linux 2 에서의 설치만 진행하도록 하겠다. Amazon Linux 2(x86_64) 설치 방법 Amazon Linux 2에 있는 yum-config-manager를 사용하여 설치를 진행한다. 기본적으로 패키지 매니저를 사용하기 때문에 root 계정을 사용하여 진행을 한다. yum install -y yum-utils yum-config-manager --add-repo https://rpm.releases.hashicorp.co..

클라우드 상에서 머신 이미지를 생성하기 위해서 Packer를 사용을 해보려고 삽질을 한다. 도큐먼트 위주로 작성을 할 것이며, 중간 중간 AWS를 사용하여 테스트를 진행할 것이다. Packer를 사용하는 이유 패커를 사용하는 이유는 패커 사이트에 대문짝만하게 나와있다. 1. 빠른 인프라 배포 수초 안에 Packer로 만든 이미지를 사용하여 테라폼으로 배포를 하게 되면 몇초 안에 빠르게 배포를 할 수 있다. 2. 다중-환경에 대한 이식성 동일한 이미지를 사용하여 개발, 스테이징, 프로덕션 환경에서 사용할 수 있다. 3. 안정성 향상 Packer에서 설치 및 구성한 안정적인 이미지에서 인스턴스를 프로비저닝하면 버그가 있는 소프트웨어가 배포되지 않으므로 안정성이 향상이 된다. 4. 개발 / 프로덕션 환경의 동..

Bastion Host가 없는 환경 먼저 Bastion Host가 없는 상황부터 접속을 진행 하겠습니다. Bastion Host가 없는 환경이라면 Public Subnet에서 직접적으로 인스턴스에 접근이 가능해야 합니다. 이럴때에는 인스턴스에 EIP 또는 Public IPv4가 등록이 되어 있어야 합니다. 1. 접근할 수 있는 IP 확인하기 위에서 보이는 바와 같이 Public IPv4 또는 EIP 둘 중 하나로 접근을 진행하시면 됩니다. 2. 접근 시 필요한 Key 확인 인스턴스 생성 시 같이 생성하였던 Key-pair 이름을 확인합니다. 3. 인스턴스 접속하기 Putty 같은 SSH Client tool을 사용하거나 terminal 환경을 사용할 수 있는 환경에서 접속을 진행합니다. 기본적으로 Ama..

클라우드를 실현하고 지탱하는 기술 중 주 된 기술들을 간단하게 알아보겠다. 서버 가상화 기술의 장점 서버 가상화란 하나의 물리적 서버 리소스에 여러 개의 서버 환경을 할당하고, 각각의 환경에 OS와 애플리케이션을 실행할 수 있게 만들어 준다. 물리 서버의 경우, 모든 리소스를 사용하는 상황이 흔치 않으므로, 리소스가 남는 경우가 많다. 이럴 때 가상화를 사용하면 서버 리소스를 최대한 많이 사용할 수 있다. 이로 인해 물리 서버의 수가 줄어들기도 하며, 각각의 환경이 독립적이므로 보안적으로도 이득을 얻을 수 있다. 서버 가상화 기술 서버 가상화 기술은 주로 하이퍼바이저, 호스트 OS, 컨테이너 3종류로 나뉜다. 하이퍼바이저 하나의 물리 서버 위에 하이퍼바이저라는 가상화 소프트웨어를 동작시키고, 그 위에 L..

클라우드 서비스를 사용하기 전에 기존의 IDC 환경을 클라우드로 옮길 시의 방법과 새로 구축할 때의 방법을 알아본다. 클라우드 이전을 위한 4가지 접근 방법 기존의 IDC 시스템을 클라우드로 이전할 때 4가지의 방법을 고려할 수 있다. 애플리케이션 단위 시프트 시스템 전체에 영향을 적게 미치는 애플리케이션을 클라우드로 옮긴다. 리프트 앤 시프트 시스템 구성을 최대한 바꾸지 않으면서, 기존의 IDC 환경을 클라우드로 전환하고 클라우드에 맞게 수시로 개선한다. VMware를 사용하는 환경에서는 매우 쉽게 리프트 앤 시프트 방식을 채택하여 이전할 수 있다. 기존 IT 시스템과 클라우드 네이티브의 공존 기존의 IDC 시스템을 클라우드로 마이그레이션 한 후 클라우드 기능을 일부 태책하여 표준화와 자동화를 도모한다..

우리가 현재 쓰고 있는 클라우드에 대해서 정리를 좀 해보려고 한다. 크게 섹션을 나눠서 진행하려 한다. 클라우드의 보급 배경 태초부터 시작에는....은 아니고 1980년대쯤엔 메인 프레임이라는 엄청나게 큰 컴퓨터의 시대였다. 모든 데이터를 이 메인 프레임에서 처리를 진행하였고, 단말기는 입, 출력만 했었다. 90년대쯤에는 단말기에도 처리 기능이 생기면서 분산처리가 가능한 클라이언트 서버 모델이 주류가 되었고 2000년대에는 네트워크의 고속화 및 하드웨어 퍼포먼스의 상향으로 인해 처리가 다시 서버로 집중이 되었다. 이제 2010년부터는 전 세계에 배치된 서버 리소스를 On-demand 형태로 사용가능한 클라우드 컴퓨팅 모델로 발전을 하게 되었다. 일단 여기서 이 클라우드가 보급된 배경으로 이유를 찾자면 다..

Redundant Array of Independent Disks의 약자이며, 말 그대로 여러개의 하드 디스크에 중복된 데이터를 나눠서 저장하는 기술이다. RAID는 데이터를 저장하는 다양한 방식이 존재하는 이를 레벨이라 한다. 레벨에 따라 디스크의 신뢰성을 높이거나 전체적인 성능을 향상시키는 등의 다양한 목적을 만족시킬 수 있다. 구현 방식 대체로 구현 방식으로 레이드 컨트롤러라고 하는 하드웨어를 사용하여 구현하는 방식과 펌웨어로 구현하는 펌웨어 레이드, 그리고 OS 상의 소프트웨어로 구현하는 소프트웨어 레이드의 종류가 있다. 가격면으로는 역시 하드웨어 자체를 따로 구입하는 하드웨어 레이드가 제일 비싸지만, 안정성이나 속도같은 면을 고려하면 하드웨어 레이드, 펌웨어 레이드, 소프트웨어 레이드의 순서로 ..

일단 기본적으로 AWS를 사용하고 있기에 AWS Route53에서 지원하는 DNS 레코드 유형을 정리해본다. A 레코드 IPv4 주소를 사용하여 웹 서버와 같은 리소스로 트래픽을 라우팅 하는 역할 AAAA 레코드 A 레코드와 같은 용도지만 IPv6 주소를 사용한다. CAA 레코드 Domain Record type Flags Tag Value example.com. CAA 0 issue "SomeCA.com" example.com. CAA 0 issue "amazon.com" example.com. CAA 0 issue "amazontrust.com" example.com. CAA 0 issue "awstrust.com" example.com. CAA 0 issue "amazonaws.com" exampl..

이전 글에서 언급한 것처럼 DNS에서는 각 계층의 권한 DNS 서버가 각각의 DB를 가지고 있고, 폴 리졸버가 이름 변환 처리를 하면서 계층을 순회하고 검색한다. 풀 리졸버에서는 이름 변환 비용을 낮추기 위해 캐시를 활용하기도 한다. DNS 구성 요소와 각 요소의 역할 DNS에서 위임하는 쪽을 부모(Parent)라 하고 위임받는 쪽을 자식(Child)이라고 한다. DNS 기능은 크게 정보를 제공하는 기능과 이름을 변환하는 기능으로 나눌 수 있다. 이름에 관한 정보를 제공하는 기능은 권한 DNS 서버가 제공하고 이름을 변환하는 기능은 리졸버(Resolver)가 제공한다. 리졸버는 클라이언트 애플리케이션의 이름 변환 라이브러리에 해당하는 스텁 리졸버 (Stub Resolver)와 이름 변환 서비스를 제공하는..

DNS란 IP주소를 사람이 읽을 수 있는 도메인으로 변환을 시켜주는 글로벌 시스템이다. 사용자가 "softpien.dev"와 같은 웹 주소에 접근하려 할 때, 웹 브라우저나 애플리케이션이 DNS 서버에 대해 "softpine.dev" DNS 조회를 수행하여 호스트 이름을 제공한다. 그리고 DNS 서버는 호스트 이름을 가져와서 웹 브라우저가 연결할 수 있는 숫자 IP주소로 해석해 준다. DNS가 없던 시절 DNS가 없었던 시절에는 인터넷에서 한 개의 HOSTS.TXT 마스터 파일을 공유하여 사용을 했다. 이 마스터 파일은 SRI-NIC에서 관리되며 익명 FTP로 공개되었다. HOSTS.TXT 파일에 대한 변경, 수정, 코멘트, 질문은 모두 HOSTMASTER@SRI_NIC로 메일을 보내는 방식이었다. DN..