PaaS-TA 교육 4일차

- PaaS-TA는 CFAR+CFCR을 채택하여 사용했음

- PaaS-TA는 제공 가능한 서비스가 있으며 현재 우리가 배포한 것은 only PaaS-TA 뿐이다. 선택적으로 서비스를 설치해놓고 사용자들이 사용할 수 있게 한다.

- PaaS-TA의 컨셉은 배포한 VM에 Diego Cell을 가지고 있어 컨테이너를 이 위에 올려주고 관리 역시 PaaS-TA가 한다.

- 주체는 PaaS-TA이며 다른 서비스들에는 Service Broker가 있어서 PaaS-TA가 서비스들을 인지한다. 똑같은 서비스(Mysql은 걍 Mysql임)인데 PaaS-TA가 사용하기 위해서 Broker를 가지고 있는 것이며, 살리고 죽이는 것은 BOSH가 하는 것이기 때문에 VM의 관리는 BOSH가 한다.

- 시험지 리뷰 (총 25문제 / 20문제는 5객관식, 5문제는 실습)

클라우드의 기본 속성 (리소스 공유, 네트워크를 통한 접근, 주문형 서비스, 측정 가능한 서비스)

PaaS의 장점(웹에서 사용할 수 있고, 개발에서 배포까지 짧은 라이프 사이클, 어플리케이션 배포 이후 필요한 리소스를 가져다 사용하는 구조, 환경 커스터마이징X, 이미 되어 있는 틀을 사용하는 것) - 개발자가 개발한 결과만 application이며 service는 다른 개념

PaaS 용어(Org, Space)

전통적인 application과 (확장을 위해서 증설! 메모리+ 디스크+ , scale up) 클라우드 어플리케이션(scale out)
- 모놀리스 서비스와 마이크로 서비스(API-API이기 때문에 느슨한 결합이 됨 레이턴시?)

BOSH (Release, Stemcell, Manifest(=Deployment))
- Release파일과 Stemcell을 가지고 배포를 하는 장점 (똑같은 SET을 어떤 IaaS 환경에서든지 배포할 수 있음)
원하는 형태로 여러번의 배포가 가능
- VM Life Cycle Management Tool, 관리도 해줌
- BOSH Release Block, Job Block, Network Block에 관한 이해(Manifestfile)
- bosh-deploy.sh

파스타 설치 순서
- Bosh CLI > BOSH Server > Cloud-Config > PaaS-TA Deploy
- 명령 CLI > CLI를 통한 서버 > 사용할 IaaS 정보 설정 > BOSH를 이용한 배포

PaaS-Ta 개발 도구
- PaaS를 통해 배포할 수 있는 개발 툴(WEB IDE-Eclipse CHE, 배포 Pipline, SCM 등)

PaaS-TA 구조
- Application 배포 (도움을 주는 BuildPack)
- 인증을 처리하는 component(OAuth2 - UAA)
- 빌드팩(compile - release)
	만약 JAVA라면 JAVA를 인식하고(detect) 환경을 구성해서 컴파일하는 과정(compile) - blockstore에 저장 - 컨테이너에 재배포(release)
- Service
	service broker
   
 BOSH를 통해서 오늘 한 것
 - 명령어 외우기
 bosh -e vbox -d paasta [ssh/vms/vms --vitals]
 ssh이후 sudo su - monit [summary/status]
 - jumpbox 배포
 	bosh 배포 이후 생성된 yml 안에 private ssh를 통해 key 생성 이후 bosh 로그인
 - cf cli
 	create user, org, space
    
 portal
 ssh
 credhub

---

- 테스트 환경

VM을 만들어야 하지만 여건이 안될때에(테스트를 하기위해) BOSH-Lite를 사용했다. (BOSH-Local이라는 새로운 기능도 나왔으며 사용할 수 있다고 한다)

얘네가 배포될 때에는 VM인척하는 Container들이다. 

- 실제 구축 환경

- 운영을 준비해준다.

vboxmanage startvm $(bosh int ~/workspace/bosh-deployment/state.json --path /current_vm_cid) --type headless

bosh -e vbox env

BOSH 기본 명령어

bosh -e vbox {option}

사용해보면

bosh -e vbox deployments

이 명령어는 내가 배포한 deployment 목록을 확인할 수 있다. 우리는 BOSH-Lite를 사용했기 때문에 위와 같이 나타나지만 플레이파크로 로그인해서 보면 stemcell의 이름이 VM 형태로 나타난다.

명령세트의 형태는 아래와 같다.

bosh -e [별칭] [명령어] [명령어 옵션]

paas-ta deployment로 만들어진 vms를 조회해본다.

bosh -e vbox -d paasta vms

이걸 테스트용 환경 구성에 맞는 container로 조회해본다. 점프박스로 들어가본다.

ssh jumpbox@192.168.50.56 -i jumpbox.key

cd /var/vcap/data/garden/depot

리스트를 조회해보면 vm리스트들이 나와있는 것을 볼 수 있다.

bosh -e vbox -d paasta ssh [instance]

접속 이후 root 권한
sudo su

vcap 아래에 job과 package가 존재한다.

---

BOSH를 사용하는 이유는 VM들의 수가 많아질수록 관리가 어렵기 때문이다. 그렇다면 어떻게 매니지먼트를 할까?

bosh -e vbox -d paasta vms

vm을 조회하면 status를 알려준다.

- BOSH는 자체적인 데이터베이스를 가지고 있어서 PaaS-TA라는 항목으로 VM들을 관리한다.

- BOSH는 배포한 VM과 통신하여 상태를 체크한다.

bosh -e vbox -d paasta ssh adapter
sudo su
monit summary

이를 확인하기 위해 adapter instance에 ssh로 접속하여 확인한다.

BOSH는 모니터링을 통해서 VM의 상태를 관리한다. 시나리오를 생각해보면

Inception에서 사용자가 모니터링을 요청 -> BOSH가 요청을 받고 VM의 상태를 체크(BOSH는 VM의 외부에 있음) -> API를 통해 상태를 체크하고 사용자에게 알려줌

bosh -e vbox -d paasta vms --vitals

vital 옵션을 넣으면 더 상세하게 확인할 수 있다. 이 정보는 vm의 minit status와 같은 정보이다.

bosh -e vbox -d paasta ssh adapter
sudo su
monit status

---

시험을 위한 족집게 강의

cd /home/ubuntu/workspace/paasta-4.0/deployment/paasta-deployment
vi deploy-bosh-lite.sh

paasta-deployment.yml을 들어가보면 (괄호) 쳐 진 곳이 있는데 이는 cloud-config에서 미리 정해진 경우를 뜻한다.

여기 보면 adapter는 instances가 2로 되어있지만 실제로는 1로 뜬다. 이는 deploy 할 때 -o 옵션을 통해 1개로 배포했기 때문이다. BOSH는 PaaS-TA Deploymanagement 툴이 아니라 VM Deploymanagement 툴이다.

operations/bosh-lite.yml

cred.yml을 한번 살펴본다. (yml은 key : value, tab을 사용하지 않음)

cd /home/ubuntu/workspace/bosh-deployment
vi creds.yml

jumpbox를 검색해보자.

이 키는 alias로 저장이 되어있다. (jumpbox login을 찾아보면 된다)

bosh int --path /credhub_tls/ca ~/workspace/bosh-deployment/creds.yml

---

Portal

paasta_trainee06/trainee06

BOSH CLI - VM 관리

CF CLI - PaaS-TA Control CLI

주는 아이디로 다시 로그인 했다.

nginx 생성 이후 접속해보았다.

JAVA도 만들어보았다.

이 때에 앱 이름과 호스트 이름은 서로 다른 의미를 갖는다.

앱 이름 : 스페이스 단위로 중복을 허용하지 않음 (같은 스페이스 내에 중복X)

앱 URL : 전체 공간에서 중복을 허용하지 않음 (유니크 함)

도메인 : 기본적으로 paas-ta.org 도메인을 가지며 추가를 통해 새로운 도메인을 가질 수 있음.

- 대표 IP는 하나가 되는데, Haproxy를 통해 다중으로 구성할 수 있음

Mysql 데이터베이스를 생성해본다. 다음과 같은 모양새를 지닌다. broker는 유저정보를 생성해주고, haproxy를 통해 database를 제어한다.

그리고 nginx에 mysql을 이어준다.

환경변수를 살펴본다.

어플리케이션은 환경변수를 자신의 저장공간처럼 사용할 수 있다. 이제 nginx는 mysql의 환경변수를 가지고 있기 때문에 mysql에 접속할 수 있다. 이 어플리케이션은 환경변수를 어떻게 가져올지 알기 때문에 서버의 변경이 쉽다. 

예를 들어 디비가 마이그레이션되어서 변경되었을 경우 vcap_services 에서 바로 가져오기 때문에 IP나 USER_ID, PWD에 구애없이 접속할 수 있다.

 이제 cloud-foundry cli를 사용해본다. git에 접속하며 v6 cli를 다운로드 받는다.

paas-ta는 bosh를 통해 배포된 소프트웨어일 뿐이다 >_< 운영 할 때에는 cf만 사용한다.

사용자는 로그인할 때 token을 통해 로그인하기 때문에 마지막 토큰을 따른다 (A 로그인 이후 B 로그인 하면 B의 토큰이 남기 때문에 A로 push해도 B에 배포가 됨)

로그인해본다.

cf login -a https://api.paas-ta.org --skip-ssl-validation

어플리케이션 조회

cf a

서비스 조회

cf s

plan은 service에만 있는 옵션이다. nginxtest가 bound되어있는 것을 볼 수 있다.

마켓플레이스를 조회해본다.

cf marketplace

help에서 원하는 목록을 검색하고 싶을 때

cf help -a | findstr service

서비스를 생성해본다. MongoDB에 기본 plan으로

cf create-service Mongo-DB default-plan mongtest

인스턴스들은 전부 Space안에 존재한다. 바인드 이전 바인드하려는 어플리케이션의 환경변수를 본다.

cf env [app_name]

cf bind-service test123456(어플리케이션 이름) mongtest(서비스 이름)

또한 하나의 서비스에 여러 개의 어플리케이션을 붙일 수 있다.

cf bind-service test123456 mydb123

test123456에 들어가서 서비스의 연결을 확인한다.

이 때에는 mydb123이라는 것은 한 개 만들어져 있다. 이후 어플리케이션을 붙이면 어플리케이션만 사용할 수 있는 유저를 발급해서 연결해준다. 두번째 어플리케이션은 똑같이 붙여주고 새로운 고유 유저를 생성시켜서 알려준다. 데이터베이스는 같지만 유저는 다르다는 것이다.

어플리케이션 1

어플리케이션 2

보면 접근하는 DB의 이름은 같지만 USER 네임이 다르다.

 이미 존재하는 데이터베이스 서버 안에 create database를 통해  데이터베이스를 만들고 유저만 따로 부여해주는 것이다.

K8S랑은 다르게 /bin/bash 접속이 아닌 ssh 접속을 해야한다.

cf ssh nginxtest

cf ssh nginxtest -L (로컬이라 생략)8082:10.10.5.15:3306

포트포워딩을 이용해서 내부망에 접근할 수 있다. 로컬에서 서비스 중이므로 로컬에 다시 ssh 접근 한 다음 Mysql이 서비스 중인 IP로 접속해야 한다. 데이터베이스에 접근하고 싶다면 바인드 한 다음 유저의 정보를 취득하고 SSH로 접근이후 workbench와 같은 툴을 통해서 데이터베이스에 접속할 수 있다.

 제공하고 있지 않은 외부 서비스를 사용하고 싶을 때

1. config에 직접 IP를 박아넣어서 해결할 수 있다.

2. 서비스 인스턴스를 새로 생성해서 바인드 이후 사용할 수 있다. 이걸 어떻게 하는가?

포탈에서는 User Provided 생성을 클릭하면 된다.

cf create-user-provided-service /or/ cf cups
cf cups 
window cmd : "{\"username\":\"admin\",\"password\":\"pa55woRD\"}"
cf cups myextdb -p "{\"ip\":\"211.123.123\",\"username\":\"admin\",\"password\":\"admin\"}"

포탈 관련

- 포탈은 서비스가 아니다. 서비스는 브로커가 있어야 하기 때문이다.

- 포탈은 마이크로 서비스로 여러 개의 VM으로 서비스 한다.

- registration server는 IP 기반이 아닌 label 기반으로 되어 있고 gateway는 API들의 호출을 통합해주는 역할을 한다.

scm = git

pipline = jenkins