'Cloud Computing/Amazon Web Services'에 해당되는 글 18건

  1. [AWS] CloudWatch ALARM를 통한 EC2 인스턴스 모니터링 (1)
  2. [AWS] EBS 볼륨 생성
  3. [AWS] Amazon EC2 인스턴스에 Java(JDK) 설치 (2)
  4. [AWS] Amazon EC2 인스턴스 AMI 생성
  5. [AWS] Amazon EC2 인스턴스에 IP 주소 할당
  6. [AWS] Amazon EC2 인스턴스에 SFTP를 연결해보자.
  7. [AWS] Amazon EC2 인스턴스의 TIMEZONE 변경 (1)
  8. [AWS] Amazon EC2 인스턴스의 원격 ROOT 계정활성화
  9. [AWS] Amazon EC2 인스턴스에 접속해보자.
  10. [AWS] Amazon EC2 인스턴스를 사용해보자.





CloudWatch 서비스를 통해 EC2 인스턴스를 모니터링하여 ALARM기능을 활용해보자.

앞서 학습한 바와 같이, CloudWatch는 많은 AWS 리소스에서 데이터를 수집, 저장, 집합, 제공하면서 현재는 EC2 인스턴스와 일래스택 로드 밸런서로부터 수집된 데이터를 기본으로 한 메트릭 정보로 EC2 인스턴스의 오토 스케일링 기능관리자에게 알람 기능등을 제공하는 서비스입니다.


CloudWatch 서비스를 통해 Alarm 규칙을 설정하고, 관리자에게 메일링 서비스를 적용하는 방법을 알아보겠습니다.


Fig.01: AWS EC2 Dashboard에 접속하여, CloudWatch 서비스를 선택합니다.


Fig.02: 아래쪽의 Tokyo region과의 Service Health를 확인 가능합니다.

CloudWatch Alarm을 생성하기 위해 좌측의 Alarms 버튼을 선택합니다.


Fig.03: 아직 아무런 Alarm이 설정되지 않은 상태입니다.

윗쪽의 Create Alarm 버튼을 선택하여 Alarm을 생성합니다.


Fig.04: 첫 화면에서는 Alarm을 지정할 수 있는 서비스들의 목록이 나옵니다.

그 중에서 EC2 인스턴스 모니터링하기 위해서 EC2 Metrics를 선택합니다.


Fig.05: EC2 인스턴스의 리스트가 나타납니다.

현재 제가 설정하고 싶은 EC2 인스턴스의 CPU 점유율을 모니터링 하기 위해 원하는 InstanceName과 InstanceId를 파악하기 위해 EC2 Instance console로 이동하여 확인합니다.


Fig.06: 기존 Alarm 설정 화면에서 설정하고자 하는 EC2 InstanceId와 Name을 파악하고, 돌아갑니다.

(물론 숙지하고 있으셨다면, 해당 과정은 Skip하셔도 됩니다. )


Fig.07: 다음 단계로 Alarm의 세부설정을 시작합니다.

Name : Alarm의 이름

Description : Alarm에 대한 설명

Whenever : 임계점 설정 (테스트를 위하여 CPU점유율 30%보다 클 경우 Alarm 1s 동안 동작합니다.)

Actions : 임계점에 도착하였을 때 실행되는 행동

(3가지 상태 :OK- 문제 없음, ALARM - 알람의 요건을 충족, INSUFFICIENT_DATA - 알람을 동작시키기 위한 조건을 불충족)

아래의 AutoScaling Action을 통하여 AutoScaling이 가능하고, EC2 Action으로 설정할 경우, EC2 Instace를 삭제, 정지 등을 할 수 있으며, 새로운 Notification을 추가할 수 있습니다.

현재는 새로운 Topic을 생성하여, Email로 Alarm을 받기위하여 설정합니다. (SES- Simple Email Service를 통한 메일 전송)


Fig.08: 해당 Alarm을 선택할 경우, 아래의 세부정보가 표시됩니다.

(그래프는 이전 테스트로 인하여 다를 수 있습니다.)


Fig.09: EC2 Instance console에서도 해당 EC2 Instance를 선택하고 Monitoring 탭을 선택하면 상세 정보를 볼 수 있습니다.


Fig.10: 해당 EC2 Instance에 일부러 부하 테스트를 통하여 인스턴스에 부하를 줍니다.

부하 테스트는 Stress Tool을 이용하여 진행하였습니다.


Fig.11: CloudWatch Dashboard를 보면 해당 Alarm이 발생한것을 알 수 있습니다.


Fig.12: 해당 Alarm을 선택하면 아래의 Detail 부분을 통하여 부하를 체크할 수 있습니다.


Fig.13: EC2 Instance Dashboard를 통해서도 확인 가능합니다.


Fig.14: Alarm규칙에 설정해 둔 메일로 Alarm이 전송되었습니다.


Fig.15: 메일링 서비스를 통하여 해당 Alarm을 받아볼 수 있습니다.


저작자 표시 비영리 동일 조건 변경 허락
신고

[AWS] EBS 볼륨 생성





EBS 볼륨을 생성하여 Amazon EC2에 Mount 해보자.

Amazon EC2를 생성하면 EBS 볼륨을 같은 가용 영역에 있는 인스턴스에 볼륨으로서 첨부할 수 있습니다. 인스턴스가 이미 실행되고 있으므로 그것이 어느 영역에서 실행되고 있는지 파악해보고, EBS 볼륨을 생성하여 Attach 하는 과정에 대해 알아보겠습니다.


Fig.01: AWS EC2 Dashboard에 접속하여, Instance 뷰를 선택합니다.

아래쪽의 인스턴스의 상세 속성정보에서 Disk 관련 정보를 확인할 수 있습니다.


Fig.02: AWS EC2 Dashboard 왼쪽의 Volumes 페이지로 이동하여 Create Volume을 클릭하여 새로운 Volume을 생성합니다.


Fig.03: Volume Type과 Size를 지정합니다.

Size는 Gib(gigbyte) 단위로 입력받습니다. 원하는 볼륨 크기를 입력하고 Create 버튼을 누릅니다.


Fig.04: EBS Volumes 목록에 새로운 볼륨이 추가되고, 몇 초 기다린 후에 Refresh 버튼을 누르면 상태가 Available로 변경됩니다.

Available로 변경된 Volume을 해당 인스턴스에 Attach 작업을 수행합니다.


Fig.05: Attach Volume을 선택하면 매핑할 Instance 종류가 표시되고, 해당 인스턴스명을 매핑해줍니다.


Fig.06: 잠시 후 Attachment Information 열에 attached단어가 표시됩니다.

이 시점에서 Volume은 Attach 작업이 완료되었지만, 아직 파일을 저장할 준비는 되어 있지 않습니다.


root : df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G  1.7G   28G   6% /
devtmpfs        486M   60K  486M   1% /dev
tmpfs           499M     0  499M   0% /dev/shm

root : mkfs -F /dev/sdf
mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
655360 inodes, 2621440 blocks
131072 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2684354560
80 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

root : mkdir /data

root : mount /dev/sdf /data

root : df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G  1.7G   28G   6% /
devtmpfs        486M   60K  486M   1% /dev
tmpfs           499M     0  499M   0% /dev/shm
/dev/xvdf       9.9G   23M  9.4G   1% /data

Fig. 07: ssh로 접속하여, disk mount 작업을 수행합니다.

이 명령어들을 실행하고 나면 /dev/sdf에 파일을 저장할 수 있습니다. 마운트 포인트를 생성하고 파일 시스템을 마운트 합니다.

영구적이고 고성능인 디스크 볼륨을 EBS에서 실행하게 되었습니다. 파일 저장 여부에 상관없이 EBS에 할당한 스토리지에 대해 요금이 청구되는 점을 유의하기 바랍니다.



저작자 표시 비영리 동일 조건 변경 허락
신고





AWS EC2 인스턴스 OpenJDK를 Oracle Java(JDK)로 변경하여 설치해 보자.

기본 AWS AMI 설치를 하게 되면, 자동적으로 OpenJDK가 설치됩니다.

기존 OpenJDK 버전이 1.7 보다 현재 Oracle Java(jdk)가 1.8로 버전이 더욱 높고, 개발환경과 동일하여 1.8로 재 설치를 하는 과정입니다. AWS EC2 인스턴스에 기존 Java를 교체하는 작업을 소개합니다.

wget, rpm등 여러가지 방법이 존재하지만, 필자는 압축 파일을 다운로드 받은 후 설치하겠습니다.


1) Java Download(http://www.oracle.com/) 및 SFTP를 활용하여 파일 전송



Fig.01: Oracle 홈페이지에 접속합니다.


Fig.02: 상단의 매뉴중  Download 에 있는 Java for Developers를 선택합니다.


Fig.03: Java Platform(JDK)를 선택합니다.


Fig.04: Accept를 선택하고, 각자의 환경(bit, os)에 맞는 JDK를 다운받습니다.


Fig.05: SFTP tool을 활용해서 AWS EC2 인스턴스로 해당 파일을 전송합니다.


2) 기존 Java 변경 및 최신의 Java로 재 설치

[ec2-user@ip-172-31-7-180 ~]$ ls
jdk-8u11-linux-x64.gz

[ec2-user@ip-172-31-7-180 ~]$ pwd
/home/ec2-user

[ec2-user@ip-172-31-7-180 ~]$ su - root
Password:
Last login: Fri Aug  8 17:35:14 KST 2014 on pts/0

[rootr@ip-172-31-7-180 ~]# mv /home/ec2-user/jdk-8u11-linux-x64.gz ./

[rootr@ip-172-31-7-180 ~]# ls
jdk-8u11-linux-x64.gz

[rootr@ip-172-31-7-180 ~]# ll
합계 155300
-rw-rw-r-- 1 ec2-user ec2-user 159019376  8월  8 17:36 jdk-8u11-linux-x64.gz

## 권한 변경
[root@ip-172-31-7-180 ~]# chown root:root jdk-8u11-linux-x64.gz

[root@ip-172-31-7-180 ~]# ll
합계 155300
-rw-rw-r-- 1 root root 159019376  8월  8 17:36 jdk-8u11-linux-x64.gz


# 기존 java 확인
[root@ip-172-31-7-180 ~]# java -version
java version "1.7.0_65"
OpenJDK Runtime Environment (amzn-2.5.1.2.43.amzn1-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

[root@ip-172-31-7-180 bin]# which java
/usr/bin/java

## 기존 java link 삭제
[root@ip-172-31-7-180 bin]# unlink /usr/bin/java

[root@ip-172-31-7-180 bin]# cd

[root@ip-172-31-7-180 ~]# tar -xvf jdk-8u11-linux-x64.gz

## 최신 java 설치
[root@ip-172-31-7-180 ~]# mv jdk1.8.0_11 /usr/bin/

## 최신 java link 생성
[root@ip-172-31-7-180 bin]# ln -s jdk1.8.0_11/ java

[root@ip-172-31-7-180 bin]# cd

## profile path 설정 및 적용
root@ip-172-31-7-180 ~]# vi .bash_profile

export JAVA_HOME=/usr/bin/java
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH="."

[root@ip-172-31-7-180 ~]# . .bash_profile

## java version 확인
[root@ip-172-31-7-180 ~]# java -version
java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)


저작자 표시 비영리 동일 조건 변경 허락
신고





AMI(Amazon Machine Image)을 생성해보자.

AMI 카달로그

EC2 AMI 카달로그는 마켓플레이스 홈페이지(http://aws.amazon.com/amis)에서 확인이 가능합니다.

AMI 카달로그에는 EC2 AMI가 범주별로 나뉘어서 목록으로 제시되어 있습니다. 첫 번째 범주인 Amazon Web Services에는 Amazon에서 제공하는 AMI가 포함됩니다. 두 번째 범주인 Community에는 AWS 개발자 커뮤니티 구성원이 만든 AMI가 포함됩니다. 나머지 범주에는 오라클, 썬, IBM 같은 회사에서 제공하는 AMI 목록이 들어갑니다. 해당 AMI를 선택하게 되면 AMI에 관련된 상세 정보들이 표시됩니다.


Fig.01: AWS 마켓플레이스 홈페이지 모습입니다.


Fig.02: 해당 AMI를 선택할 경우, 이와 같이 AMI 상세 정보가 표시됩니다.


AMI 선택

프로젝트에 사용할 AMI를 선택하기 전에 많은 요소를 고려해야 합니다. 무엇을 선택하느냐에 따라 Amazon EC2를 규모 있고 효율성 있게 사용할 수 있습니다.

CPU 워드 크기운영체제를 선택해야 하고, 일부 인스턴스는 운영체제 배포판도 선택해야 합니다. Fedora, Debian, Ubuntu, openSUSE, Red Hat Enterprise Linux, Oracle Enterprise Linux, Gentoo를 포함해 많은 리눅스 배포판에서 EC2를 사용할 수 있습니다. 여기서 고려해야 할 사항들은 아래와 같습니다.

- 기존 시스템과의 호환성

- 배포판의 평판

- 각 배포판의 고유한 기능(ex. 패키지 관리)

- 상용 지원의 가능성

- 특수 애플리케이션에 대한 지원


커스텀 AMI 생성

자신의 AMI를 생성하여 파트너나 다른 사람들과 그 설정된 이미지를 공유하고 싶을 경우 커스텀 AMI를 생성합니다.

그 전에, EC22 인스턴스를 사용자 정의하는 방법에 대해 알아보겠습니다.

No Configuration(설정 없음) : 기존에 만든 AMI로 작업을 처리할 수 있습니다. 필요로하는 모든 것을 포함할 수 있고 소스 코드를 외부 소스 코드 제어 시스템이나 EBS 볼륨에 저장할 수 있습니다.

Manual Configuration(수동 설정) : 기본 방법으로 AMI를 시작한 다음 AMI를 수동으로 설정할 수 있습니다. 리눅스 시스템에서는 필요한 모든 패키지를 하나의 명령어로 설치할 수 있습니다.

Automated Configuration(자동 설정) : 인스턴스가 기동될 때 사용자 데이터의 문자열을 각 EC2 인스턴스로 넘길 수 있습니다.

Automated Role-based Configuration(자동화된 역할 기반 설정) : 시스템이 여러 계층에 통합돼 있고 각 계층에 대한 시스템 설정이 별개라면 각 계층을 커스터마이징 하기 위해서 자동 설정 모델을 확장할 수 있습니다.


EBS 기반 AMI가 나오면서 AMI 생성 과정은 더욱 간단해졌습니다. AMI 생성 단계는 다음과 같습니다.

1. 계획 수립 : 처리하고 싶은 것을 결정

2. 이미지 준비 : 재사용 가능 이미지를 생성

3. 이미지 생성 : 이미지의 EBS 스냅샷을 생성

4. 재사용 : AMI의 복사본 여러 개를 기동

5. 공유 : AMI가 다른 것에 접근할 수 있게 만듬


계획 수립

이 단계에서는 AMI의 목적과 내용을 파악해야 합니다. 추가 패키지를 로드할 수 있으며, AMI에 특수한 코드나 데이터를 미리 올려놓아서 특수한 데이터를 AMI의 사용자가 이용할 수 있게 만들 수 있습니다.


이미지 준비

이미지는 AMI에 패키징된 파일들의 집합입니다. 이 파일 집합을 로컬(EC2가 아닌) 머신에 준비하거나, EC2 인스턴스에 준비할 수 있습니다. EC2 인스턴스를 사용하고 있다면 머신의 루트 파일 시스템을 이미지 기반으로 사용할 수 있습니다. 이미지 생성 과정에서는 모든 파일을 루트 파일 시스템에 올립니다. 이 과정에서 다른 파일 시스템(로컬이나 EBS)에 있는 파일은 배제되고 실행중인 인스턴스와 무관한 상태(일래스틱 IP 주소, EBS 볼륨은 캡처 대상 제외)는 캡처하지 않습니다.


이번 포스팅 글에서는 기존의 사용하고 있는 인스턴스를 대상으로 이미지를 생성하겠습니다.


이미지 정리

이미지 생성 과정에서는 루트 파일 시스템의 모든 파일이 복사되어, 만약 포함하고 싶지 않은 목록이 있다면 과감하게 그 파일을 초기화 시킵니다. 그렇지 않으면 그 파일에 설정된 정보가 똑같이 AMI에 기록됩니다.

아래는 만약 로그파일, 쉘 히스토리 파일, AWS 키등을 배제하고 이미지를 만들고 싶을 경우, 이를 처리하는 예입니다.

root : rm ~/.bash_history
root : cd /var/log
root : > cron
root : > maillog
root : > secure
root : > spooler
root : > yum.log
root : > httpd/error_log
root : > httpd/access_log


이미지 생성

다음 단계는 번들을 Amazon S3로 업로드 하는 단계입니다. 이 작업을 하기 위해서 AWS 접근 키 ID, 비밀 접근키, 사용할 수 있는 S3 버킷이 필요합니다.


Fig.03: Instance 페이지 인스턴스 목록 중에서 AMI 생성 대상 인스턴스를 우클릭한 후 Create Image를 클릭합니다.


Fig.04: 인스턴스에 이름과 설명을 부여하고, Create Image 버튼을 클릭합니다.

인스턴스는 이미지 생성 과정의 일부로서 재 부팅됩니다. 따라서 인스턴스가 조금 시간이 지나면 다시 available로 변경될 것이고, 생성 과정에서는 로그인이 불가능합니다.


Fig.05: 잠시 후 AMI 생성 완료 메시지가 표시됩니다.


Fig.06: EC2 Dashboard에서 AMIs 페이지를 클릭해보면, 해당 이미지 파일이 생성중에 있음을 확인 할 수 있습니다.

이미지 생성 과정에서 걸리는 시간은 인스턴스의 루트 파일 시스템의 크기에 따라 달라집니다.


Fig.07: AMI가 생성완료 되었습니다.


AMI 재사용 및 공유

AMI가 생성완료 되었으면, AMIs 페이지에서 Launch Instance Wizard로 AMI의 인스턴스를 찾고 기동할 수 있습니다. 퍼미션은 계정을 갖고 있는 자신에게만 있고, AMI의 가시성은 Private로 지정돼 있습니다. 새로운 AMI를 특정 AWS사용자나 AWS 커뮤니티 전체와 공유도 가능한데, 이를 공유하려면 AWS 계정번호가 있어야 합니다. 이 계정번호는 아래와 같은 방법으로 생성합니다.


Fig.08: 공유할 해당 AMI 오른쪽클릭을 하여 Modify Image Permissions를 선택합니다.


Fig.09: 해당 화면에서 공유할 AWS 사용자의 계정번호를 입력하고 퍼미션을 부여합니다.

만약, AWS 커뮤니티 전체와 AMI를 공유하려면 Public을 선택하면 공유가 가능합니다.


API를 이용하여 AMI 생성

EC2 Console을 이용하는 방법 외에도 AMI 이미지를 생성할 수 있습니다. 방법은 아래 두개의 API를 통하여 생성 가능합니다. 본 포스팅에서는 방법은 생략하겠습니다.

- Amazon EC2 API Tools (http://aws.amazon.com/developertools/351)

- Amazon EC2 AMI Tools (http://aws.amazon.com/developertools/368)


저작자 표시 비영리 동일 조건 변경 허락
신고





AWS EC2 인스턴스에 Elastic IP를 할당해보자.

인스턴스에 영구적인 IP주소를 할당하는 방법이 있습니다. AWS EC2 인스턴스를 기본 생성하여 원격 접속 할 경우 Public DNS를 입력하여 접근하여야 하는데, 이것은 인스턴스가 재부팅 될 때마다 변경되어서 매우 불편합니다. 영구적인 IP 주소 Elastic IP를 해당 인스턴스에 할당하게 되면 이 문제를 해결 할 수 있습니다.


Fig.01: AWS EC2 Dashboard에 접속하여, 왼쪽의 Elastic IP를 클릭합니다.


Fig.02: 기존의 할당되어 있는 Elastic IP가 표시되고, 새로운 Elastic IP 할당을 위해 Allocate New Address 버튼을 클릭합니다.


Fig.03: Allocate New Address 메시지가 나오고, Yes버튼을 클릭합니다.


Fig.04: 영구적인  Elastic IP가 할당되었습니다.

이 시점에서 주소값은 다른 EC2 인스턴스와는 연계되어 있지 않는 상태입니다.

IP주소를 할당받고 매핑하지 않을 경우 금액이 발생하며, 최초 1개의 Elastic IP는 무료입니다.


Fig.05: 할당받은 주소를 선택하고, Associate Address 버튼을 클릭합니다.


Fig.06: 연계할 인스턴스를 선택합니다.


Fig.07: Elastic IP가 할당되었고, instance 페이지에서 확인 가능합니다.

이제는 Public DNS가 아닌 IP 주소 값으로 접속이 가능합니다.


저작자 표시 비영리 동일 조건 변경 허락
신고





AWS EC2 인스턴스에  SFTP로 연결하여 보자.

AWS EC2를 사용하다보면, 일반 Linux에서 운영할 때처럼, 서버에 SFTP 툴을 이용하여 접근하여 파일 전송을 하는 경우가 다수 있습니다. 이럴 경우 앞에서 만들어둔 key 파일을 이용하여 AWS EC2 인스턴스에 접근이 가능하며, 일반 SFTP 툴을 이용하여서 파일을 전송할 수 있습니다. 이번에는 오픈 소스이자, SFTP 툴로 인기가 있는 파일질라(filezila)를 통해 AWS EC2에 접근하는 방법을 소개합니다. 파일질라 다운로드(https://filezilla-project.org/)



Fig.01: 파일질라를 다운받아 실행합니다.


Fig.02: 상위 매뉴중 편집-설정으로 들어갑니다.


Fig.03: 설정창에서 앞서 생성해 놓았던 .ppk 파일을 인식시켜줘야 합니다.


Fig.04: 해당 EC2 인스턴스의 페어 키를 입력해줍니다.

Putty 접속과 달리 파일질라를 통해 SFTP 접속시 해당 key가 한글이나, 다른 특수 기호 폴더내에 존재하면 인식하지 못하는 장애가 있습니다.


Fig.05: key가 정확히 추가되면 확인을 눌러 인식시켜줍니다.


Fig.06: 상위 매뉴중 파일 - 사이트 관리자를 선택합니다.


Fig.07: 적절한 이름으로 새 사이트를 생성하고, HOST에는 AWS의 Elastic IP, Public DNS 입력합니다.

그리고 사용자는 ec2-user를 입력합니다.


Fig.08: 해당 EC2 인스턴스의 값을 모두 설정하면 SFTP 정상적으로 연결됩니다.

전송하고자 하는 파일을 좌에서 우로 전달합니다.


저작자 표시 비영리 동일 조건 변경 허락
신고





Timezone ?

리눅스를 새로 설치하고 나면 (AWS EC2 AMI도 Linux와 동일) 시간대(Timezone)을 맞추지 않으면, 리눅스의 date가 미국 태평양 시간인 PST로 표시됩니다. 즉 캘리포니아 현지 시간으로 표시됩니다. 이럴경우 한국 표준시인 KST로 변경해주어야 합니다.


Timezone 변경

[ec2-user@ip-172-31-7-180 ~]$ date
Fri Aug  8 06:41:49 UTC 2014

[ec2-user@ip-172-31-7-180 ~]$ sudo date
Fri Aug  8 06:42:01 UTC 2014

[ec2-user@ip-172-31-7-180 ~]$ sudo cat /etc/localtime
TZif2UTCTZif2UTC
UTC0

[ec2-user@ip-172-31-7-180 ~]$ sudo rm /etc/localtime

[ec2-user@ip-172-31-7-180 ~]$ sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

[ec2-user@ip-172-31-7-180 ~]$ date
Fri Aug  8 15:48:27 KST 2014

[ec2-user@ip-172-31-7-180 ~]$ sudo date
Fri Aug  8 15:48:40 KST 2014


저작자 표시 비영리 동일 조건 변경 허락
신고





AWS EC2 인스턴스에서 ROOT 계정을 활성화 해보자.

이제 AWS EC2 인스턴스에 SSH로 접근이 가능합니다.

하지만 EC2 인스턴스에 ec2-user만 활성화되어 있고, root 계정은 비활성화 되어 있습니다. 물론 linux sudo 명령을 이용해서 root 권한을 사용할 수 있습니다. 하지만 root 계정을 활성화 할 경우도 필요하여, root 계정을 아래와 같이 방법을 통해 활성화 해보겠습니다.


Linux CLI(Command-line interface)
[ec2-user@ip-172-31-7-180 ~]$ sudo passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

[ec2-user@ip-172-31-7-180 ~]$ sudo vi /etc/ssh/sshd_config
#PermitRootLogin no
PermitRootLogin yes

[ec2-user@ip-172-31-7-180 ~]$ sudo mkdir /root/.ssh
mkdir: cannot create directory ??root/.ssh?? File exists
[ec2-user@ip-172-31-7-180 ~]$ sudo cp /home/ec2-user/.ssh/authorized_keys /root/.ssh
[ec2-user@ip-172-31-7-180 ~]$ sudo service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]

[ec2-user@ip-172-31-7-180 ~]$ su - root
Password:
Last login: Fri Aug  8 02:02:02 UTC 2014 on pts/0
[root@ip-172-31-7-180 ~]#

Linux GUI(Graphical user interface)


Fig.01: ec2-user로 접속합니다.


Fig.02: sudo 명령어를 통해서 sshd_config파일을 vi편집기로 수정합니다.


Fig.03: 현재 ec2-user의 ssh key를 root에 복사하여 주고, sshd service를 restart 합니다.

mkdir /root/.ssh 명령에서 이미 생성되어 있는 디렉토리라는 에러가 발생 합니다.


Fig.04: 이제 외부에서 ssh를 통하여 root 계정으로 원격접속이 가능합니다.


저작자 표시 비영리 동일 조건 변경 허락
신고





AWS EC2 인스턴스를  SSH 클라이언트인 PuTTY로 접속해보자.

이전 포스팅에서 AWS EC2 인스턴스를 정상적으로 생성했습니다.

이젠 AWS EC2 인스턴스에 직접 접속하여 자신이 원하는 AWS 환경으로 구축하고 필요한 프로그램들도 설치해야 합니다.

그에 기본이 될 수 있는 SSH 클라이언트로 생성한 AWS EC2 인스턴스에 접근하는 방법에 대해 알아보겠습니다.



Fig.01: 우선 SSH 클라이언트 프로그램인 Putty를 로컬 환경으로 다운로드 합니다.

영문 Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)

한글 Putty (http://kldp.net/projects/iputty/)

Putty 한글 버전은 후반부에 나올 Putty Private Key 생성 시 에러가 발생합니다.

다운로드 완료 후, Private Key 생성을 위해 puttygen.exe를 실행합니다.


Fig.02: Putty Key Generator 실행 후 AWS EC2 키를 Load하기 위한 Load작업을 수행합니다.


Fig.03: 앞서 저장해 놓은 AWS EC2 인스턴스의 키를 해당 경로에서 선택합니다..


Fig.04: 정상적으로 Load 되었습니다..

(이 때, 한글 Putty는 에러가 발생합니다.)


Fig.05: Putty Private Key를 Save private key를 선택하여 저장합니다.


Fig.06: 키 저장시 암호 생성여부를 물어봅니다.

현재 저는 암호를 지정하지 않고 Key만 저장하였습니다.


Fig.07: 적당한 위치에 적당한 이름으로 저장합니다.


Fig.08: AWS EC2 key는 .pem으로 저장되고, Putty Private Key는 .ppk 확장자로 저장됩니다.

 AWS EC2에 접속하기 위해서는 .pem key가 필요하고, ssh 접속을 위해서는 .ppk키가 필요합니다.

.pem key (AWS Direct Connection)

.ppk key (AWS SSH Connection)


Fig.09: Putty Tool을 실행하고 Host Nmae에 Public DNS 값을 입력합니다.

만약 Elastic IP값을 발급받았으면, Elastic IP를 입력해도 됩니다.


Fig.10: AWS EC2 Dashboard 에서 해당 인스턴스의 Public DNS 값을 확인하고 기입합니다.


Fig.11: Putty 좌측 SSH 인증 탭에서 앞서 생성한 .ppk key를 Browse 버튼을 눌러서 Import 합니다.


Fig.12: 해당 Key로 Import 진행합니다.

해당 Key가 저장되어 있는 폴더는 할글로 이루어지면 안됩니다 !! (사진처럼 Import하면 불가)


Fig.13: 개인 설정에 맞춰서 세션을 저장합니다.


Fig.14: 처음 접속이므로 key 저장여부를 확인하고 접속합니다.


Fig.15: root 로 접속합니다.


Fig.16: root로 접속하게 되면 에러가 발생합니다.

이 에러는 Amazon Linux AMI로 인스턴스 구성시에는 ec2-user로 접근해야 합니다


Fig.17: AWS 매뉴얼을 보면 각 AMI에 따라 접속할 수 있는 유저가 지정되어 있습니다. (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)


Fig.18: ec2-user로 재 접근시에 성공적으로 접근 가능합니다.


저작자 표시 비영리 동일 조건 변경 허락
신고