43/120
vscode
설치
PS C:\Users\Playdata> choco install vscode
실행 명령어
PS C:\Users\Playdata> code [편집할 파일]
SSH
패스워드 기반의 인증
- A는 B의 공개키
/etc/ssh/ssh_host_<Algorithm>.pub
/etc/ssh/ssh_host_<Algorithm>
- RSA - default
- DSA
- ECDSA
- (B 시스템에 최초 접속시)
A의 시스템의 사용자에게 B의 공개키(지문) 맞는지 확인?
- YES
- A의
~/.ssh/known_hosts
파일에 B의 공개키 등록
- B의 IP/Domain
- B의 공개키
- ID/PWD 질의(인증)
키 기반의 인증
- A에서 (인증용)키 쌍을 생성
ssh-keygen
~/.ssh/id_rsa
: 개인키
~/.ssh/id_rsa.pub
: 공개키
- B에 A의 공개키 등록
- B 시스템의
~/.ssh/authorized_keys
: 클라이언트의 공개키 등록
- EC2(클라우드 인스턴스): A에서 지정한 A의 공개키 등록
- BM, VM:
ssh-copy-id
명령으로 등록
- B에 패스워드 인증 방법이 활성화 되어 있어야 함
- (B 시스템에 최초 접속시)
A의 시스템의 사용자에게 B의 공개키(지문) 맞는지 확인?
- YES
- A의
~/.ssh/known_hosts
파일에 B의 공개키 등록
- B의 IP/Domain
- B의 공개키
- A의 개인키로 인증
PS C:\Users\Playdata> choco install vscode
PS C:\Users\Playdata> code [편집할 파일]
패스워드 기반의 인증
- A는 B의 공개키
/etc/ssh/ssh_host_<Algorithm>.pub
/etc/ssh/ssh_host_<Algorithm>
- RSA - default
- DSA
- ECDSA
- (B 시스템에 최초 접속시)
A의 시스템의 사용자에게 B의 공개키(지문) 맞는지 확인?
- YES - A의
~/.ssh/known_hosts
파일에 B의 공개키 등록- B의 IP/Domain
- B의 공개키
- ID/PWD 질의(인증)
키 기반의 인증
- A에서 (인증용)키 쌍을 생성
ssh-keygen
~/.ssh/id_rsa
: 개인키
~/.ssh/id_rsa.pub
: 공개키 - B에 A의 공개키 등록
- B 시스템의
~/.ssh/authorized_keys
: 클라이언트의 공개키 등록 - EC2(클라우드 인스턴스): A에서 지정한 A의 공개키 등록
- BM, VM:
ssh-copy-id
명령으로 등록
- B에 패스워드 인증 방법이 활성화 되어 있어야 함
- B 시스템의
- (B 시스템에 최초 접속시)
A의 시스템의 사용자에게 B의 공개키(지문) 맞는지 확인?
- YES - A의
~/.ssh/known_hosts
파일에 B의 공개키 등록- B의 IP/Domain
- B의 공개키
- A의 개인키로 인증
기본 로그인 사용자
- Amazon Linux: ec2-user
- Ubuntu: ubuntu
- Debian: debian
- Centos: centos
- RHEL: cloud-user
- vagrant: vagrant
- ...
서버의 SSH 공개키 지문 확인
ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
서버의 SSH 공개키 미리 확인
ssh-keyscan 서버IP
ssh-keyscan -t <rsa|ecdsa> 서버IP
지문 확인
ssh-keyscan -t ecdsa 서버IP | ssh-keygen -l -f -
미리 서버의 공개키 등록
ssh-keyscan -t ecdsa 서버IP >> ~/.ssh/known_hosts
/etc/ssh/ssh_config
: 클라이언트 설정 파일/etc/ssh/sshd_config
: 서버의 설정 파일
/etc/ssh/sshd_config
를 수정하여 패스워드 인증, 키 인증의 여부를 설정 가능
PasswordAuthentication no # 패스워드 인증
GSSAPIAuthentication yes # 키 인증
키 기반 인증 구성
Client
1. ssh-keygen
을 통해 키를 생성
[vagrant@controller ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/vagrant/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/vagrant/.ssh/id_rsa.
Your public key has been saved in /home/vagrant/.ssh/id_rsa.pub.
The key fingerprint is:
실제상황에서는 passphrase를 설정해야 함
ssh-keyscan
으로 서버의 공개키를 known_hosts파일에 등록
ssh-keyscan -t ecdsa 서버1 IP >> ~/.ssh/known_hosts
ssh-keyscan -t ecdsa 서버2 IP >> ~/.ssh/known_hosts
ssh-copy-id
로 authorized_keys 파일에 원격 호스트의 키를 복사
ssh-copy-id vagrant@서버1 IP
ssh-copy-id vagrant@서버2 IP
Windows에서 Vagrant SSH 접근
Vagrant 파일이 있는 곳에서 vagrant ssh <VM_NAME>
로 접근 가능
ssh -i .\.vagrant\machines\controller\virtualbox\private_key IP
vagrant가 private_key를 자동으로 참조하여 접근이 가능
SSH 클라이언트 설정 파일을 수정하여 접근
~/.ssh/config
을 수정
설정가능한 항목들
Host [VM이름]
HostName IP/hostname # 접속할 서버의 IP
User vagrant # 접속할 사용자의 이름
IdentityFile private_key 파일의 경로
.ssh 디렉토리로 이동하여 수정해야함
윈도우에서 EC2로 접속
- EC2 인스턴스 키의 지문확인
ssh-keyscan -t ecdsa 서버IP | ssh-keygen -l -f -
- ~/.ssh/config 편집
Host bastion
HostName 퍼블릭IP/탄력적IP
User ec2-user
IdentityFile C:\Users\Playdata\Downloads\ansibleTestKey.pem # 인스턴스 생성 시 발급한 키의 위치
- ssh 로 접속
PS C:\Users\Playdata> ssh bastion
미리 확인한 지문과 일치하는지 비교
Last login: Tue Apr 12 11:35:55 2022 from *
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
14 package(s) needed for security, out of 17 available
Run "sudo yum update" to apply all updates.
Ansible
오픈소스 IT 자동화 도구, Ansible 자동화를 사용해 소프트웨어를 설치하고, 일상적인 태스크를 자동화하고, 인프라를 프로비저닝하고, 보안 및 컴플라이언스를 개선하고, 시스템에 패치를 적용하고, 조직 전체에 자동화를 공유 가능
IaC
Infrastructure as Code: 코드형 인프라
컴퓨터의 인프라 구성을 소프트웨어를 개발하는 것처럼 코드로 작성하는 것
장점
- 비용 절감
- 빠른 속도
- 안정성
- 재사용성
- 버전 관리
구성 관리 / 배포
구성 관리: Configuration Management
패키지 설치, 설정 파일, 파일 복사 ...
배포: Provisioning
리소스 새로 생성
리소스 변경, 삭제, 관리
구성관리 도구: Ansible, Chef, Puppet, SaltStack ...
배포: Terraform, Vagrant, AWS CloudFormation
가변 인프라 / 불변 인프라
- 가변(Mutable) : Ansible
여러 관리 대상 인프라가 독립적으로 관리되며 별도의 변경 사항을 가지는 형태 - 불변(Immutable) : Terraform
인프라가 배포된 후 절대로 변하지 않는 인프라
EC2 인스턴스를 이미지화 하는 것과 비슷
참고: 애완동물 vs 소떼(가축)
pets : 온프레미스, cattle : 클라우드
pets 쉽게 대체 될 수 없는, 결코 죽어서는 안 되는 시스템
Cattle 자동화된 툴을 이용하여 두 개 이상의 서버로 구성된 시스템
반려동물이 아프면 병원에 가서 치료하듯, ‘Pets’ 시스템에서는 서버에 장애가 생기면 그 장애를 바로 고쳐 해당 서버를 계속 사용. 반면, ‘Cattle’ 시스템에서는 장애를 고치는 대신 장애 서버를 제거하고 새로운 서버로 바로 대체
절차적 / 선언적
절차적(순서O) : Ansible
선언적(순서X) : Terraform, Kubernetes
마스터 및 에이전트 유무
마스터, 에이전트: Chef, Puppet, SaltStack
Ansible 설치
controller
[vagrant@controller ~] sudo yum install centos-release-ansible-29 -y
[vagrant@controller ~] sudo yum install ansible -y
설치 확인
[vagrant@controller ~]$ ansible --version
ansible 2.9.27
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/home/vagrant/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.5 (default, Apr 2 2020, 13:16:51) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
인벤토리
Ansible에서 관리할 호스트 목록을 정의
vi inventory.ini
# inventory.ini
관리할 서버의 IP를 정의
Ad-hoc 명령
ansible 모듈
앤서블에서 실행된 하나하나의 명령
yum 모듈로 httpd 패키지 설치
ansible 서버IP -i inventory.ini -m yum -a "name=httpd state=present" -b
항목 | 설명 |
---|---|
ansible | ad-hoc 명령 |
서버IP | 관리 노드(인벤토리 파일 정의 되어 있어야 함) |
-i inventory.ini | 인벤토리 파일명 |
-m yum | 모듈 이름 |
-a | 모듈 파라미터 |
-b | 관리자 권한 취득(become) == sudo |
관리 노드의 IP는 반드시 inventory.ini에 설정되어 잇어야 함
service 모듈로 httpd 서비스 시작
ansible 서버IP -i inventory.ini -m service -a "name=httpd state=started enabled=yes" -b
Playbook
apache_install.yaml
을 편집
- hosts: 관리노드 IP
tasks: (2)
- yum: (2)
name: httpd (6)
state: present (6)
- service: (2)
name: httpd (6)
enabled: yes (6)
state: started (6)
각 행의 공백이 중요, 각 행의 숫자는 행 맨 앞에 있어야하는 공백칸의 수
- 관리자 권한으로 명령 실행
ansible-playbook -i inventory.ini apache_install.yaml -b
Ansible로 AWS EC2 인스턴스 접속 후 관리하기
- ansible에서
ssh-keygen
으로 공개키 생성
- AWS에서 키 가져오기를 통해 id_rsa.pub 내용 등록하여 키 가져오기
- 인스턴스 생성시 해당 키 적용
- ansible에서 ec2인스턴스의 지문 확인
[vagrant@controller ~]$ ssh-keyscan -t ecdsa 인스턴스IP | ssh-keygen -l -f -
- ansible(controller)에서 ec2로 접속 및 확인한 지문이 맞나 확인
[vagrant@controller ~]$ ssh ec2-user@인스턴스IP
- inventory.ini에 EC2 인스턴스 IP 추가
- ad-hoc으로 EC2 인스턴스에 httpd 설치해보기
[vagrant@controller ~]$ ansible 인스턴스 IP -i inventory.ini -m yum -a "name=httpd state=present" -b
-u ec2-user
인스턴스IP| CHANGED => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": true,
"changes": {
"installed": [
"httpd"
]
},
ssh-keygen
으로 공개키 생성[vagrant@controller ~]$ ssh-keyscan -t ecdsa 인스턴스IP | ssh-keygen -l -f -
[vagrant@controller ~]$ ssh ec2-user@인스턴스IP
[vagrant@controller ~]$ ansible 인스턴스 IP -i inventory.ini -m yum -a "name=httpd state=present" -b
-u ec2-user
인스턴스IP| CHANGED => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": true,
"changes": {
"installed": [
"httpd"
]
},
기존에는 vagrant끼리의 관리이기 때문에 사용자 지정을 하지 않아도 되었음(사용자 지정을 하지 않으면 현재 시스템에 사용자이름으로 접속 시도), 하지만 EC2의 사용자 이름은 ec2-user이므로 -u옵션을 통해 사용자이름을 지정
- Playbook으로 EC2 인스턴스 httpd 실행해보기
yaml 파일 설정
[vagrant@controller ~]$ vi httpd_start.yaml
- hosts: 인스턴스IP
tasks:
- yum:
name: httpd
state: present
- service:
name: httpd
enabled: yes
state: started
playbook 실행
[vagrant@controller ~]$ ansible-playbook -i inventory.ini httpd_start.yaml -u ec2-user -b
PLAY [인스턴스IP] ************************************************************
TASK [Gathering Facts] *********************************************************
ok: [인스턴스IP]
TASK [yum] *********************************************************************
ok: [인스턴스IP]
TASK [service] *****************************************************************
changed: [인스턴스IP]
PLAY RECAP *********************************************************************
인스턴스IP : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Author And Source
이 문제에 관하여(43/120), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@numerok/43120저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)