Tag Archives: DevOps

Serverless 서비스 사용 툴

인프라

  • Knative
  • AWS Lambda
  • GCP CloudFunction
  • Kubeless
  • Azure
  • OpenWhisk
  • Tencent Cloud
  • Alibaba Cloud
  • CloudFlare
  • fn??
  • spotinst

프레임웤?툴? 엄청많음

그중 오픈소스+무료가능 확인된것들

  • serverless
  • jets

DevOps 환경별 구분

개발 및 배포 단계

  • Dev,Devel,Development – 개발자 개발중
  • QA,Alpha – QA자 QA중
  • PreProduction,Staging – 라이브자 라이브전
  • Live,Real,Production – 라이브자 라이브중

서버의 성격/위치

  • 개발자 본인 장비 – 개인용
  • 공동 관리하는 서버 – 사무실 서버,IDC,Cloud
  • 서비스 서버 – IDC,Cloud

세분화된 개발환경 구분

  • Dev Local Mock – 한개 서비스에서 연동서비스는 Mock 데이터
  • Dev Local/Remote Integration – 개발용 인프라에 연동서비스 함께
  • Test Remote Feature – 특정 기능 요소별로 테스트가능한 환경
  • Test Remote QA – QA 및 업무담당자 테스트환경 (수동 및 자동)
  • Live Remote Pre-Production – Production의 데이터까지 복제해서 만든 환경에 배포 결제 등 외부서비스 Real 연동
  • Live Remote Production – 실제 서비스 환경

테스트 종류

  • Manual Test
  • Unit Test
    • Mock API
    • Mock Data
  • Dev Integration Test
    • Real API
    • Seed Data
  • Live Integration Test
    • Real API
    • Real Data
  • Health Check

테스트 방법

  • Manual
  • Script

단계 구분

  1. Dev
    1. Local Dev Unit Test(Automatic)
    2. Local Dev Integration Test(Automatic)
    3. Git push – dev
    4. CI Build Unit Test
    5. Remote Dev Integration Test(Manual)
  2. Test
    1. Feature Test
    2. QA Test
    3. Success/Fail
  3. Live
    1. Pre-Production Test
    2. Production

현재까지의 순서

DevOps – CI/CD 시스템 구축

시스템 구성

  • 빌드, 컴파일, 유닛테스트
  • 배포 – 테스트환경 – 버전별로 분기해서 동작
    ex) ver 20171021, ver 20171106

두 버전이 동시에 돌아갈 수 있음.

latest사용 또는 특정버전 사용

  • health check

시나리오 테스트

Real서버배포 – aws, gcp 등 cloud환경 배포시 배포 완료 후 ssh daemon 종료. 접속불가. immutable. 삭제만 가능.

 

참고글

https://cloud.google.com/container-registry/

https://cloud.google.com/container-registry/docs/continuous-delivery

https://cloud.google.com/solutions/spinnaker-on-compute-engine

https://martinfowler.com/articles/continuousIntegration.html
https://martinfowler.com/bliki/ContinuousDelivery.html

요약정리는 읽어본 후

추가 다른글
https://trello.com/c/rOmLEI0u/9-%EB%A7%88%ED%8B%B4-%ED%8C%8C%EC%9A%B8%EB%9F%AC%EC%9D%98-is-design-dead

http://blog.naver.com/j6040148/120015111138

https://martinfowler.com/articles/designDead.html

https://www.gocd.org/2017/07/10/gocd-vs-spinnaker/

MSA – 의존성 관리 방법

Global Dependency Dictionary System 정도로 불러도 되려나

MSA로 서비스를 구성할 때 발생하는 문제가

어떤 서비스를 Deprecated를 시켰을 때 이전 버전을 언제까지 유지시켜야 할지가 애매하다.

즉각적으로?

한달이상 호출이 없을 때?

모니터링 툴 돌리다가 수동으로?

그냥 소스코드 내부에 /v1 /v2 /v20171001 같은식으로 계속 유지시켜버릴까?

이런 방법은 다 확살하지 않거나 관리가 불편하거나 다양한 문제가 있다.

디비를 변경해야 하는경우에 버전업을 할 때 오류발생 가능성도 있고

 

배포시에 사전을 만들고 의존성을 갖는 프로젝트간의 관계를 가지고 있는게 좋을 것 같다.

일반적인 형태의 라이브러리나 프레임워크로 만들기는 힘들 것 같고

규칙성을 갖게 버저닝을 하고 배포를 해야할 것 같다.

v{메인버전_호환안될수있음}-버그픽스

v1_20171001-1

v1_20171001-2

버전 표기방식으로 흔히 쓰는건 이정도 아닌가

 

버그픽스버전의 경우

3번째칸은 변경되도 호환성에 문제가 없어야하고 1,2번칸이 변경될 경우 호환이 안될 가능성이 생기는걸로

버그픽스 버전이 배포되는 경우 유닛테스트 실행. 이상이 없어야만 배포허용.

 

버전업이 되는 경우

배포시 의존성을 갖는 서비스의 관리자에게 알림이 가고

유닛테스트가 실행. 오류가 나면 오류알림(해당서비스와 의존성을 갖는 서비스의 담당자)

의존성을 갖는 서비스의 담당자는 일정시일(1개월?)이내에 업데이트 권장

긴급수정 사항은 바로 업데이트

 

이 경우 배포툴에 각 개발자의 정보가 담겨있어야한다.

 

테스트환경 구성 Tutorial – Ubuntu16.04.2

꼭 한개씩 빼먹어서 기록.

chef셋팅은 여유있을때

Mysql

$ sudo apt install mysql-server mysql-common mysql-client
$ sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
--------
#bind-address = 127.0.0.1
bind-address = *
--------

$ sudo service mysql restart
$ mysql -u root -p
password : 입력

mysql> select User, Host from mysql.user;
mysql> set password for 'root'@'localhost' = password('패쓰워드');
mysql> create user 'userid'@'%' identified by '패쓰워드';
mysql> grant all privileges on *.* to 'userid'@'%';
mysql> flush privileges;
mysql> exit;

테스트계정 추가하면서 마스터권한을 줘버렸는데

권한이나 접근가능서버는 상황에 맞게 조절하면 된다

 

RabbitMQ

$ sudo apt install rabbitmq-server
사용자 추가
$ sudo rabbitmqctl add_user testuser testpassword
관리자권한부여
$ sudo rabbitmqctl set_user_tags testuser administrator
접근권한 부여
$ sudo rabbitmqctl set_permissions -p / test ".*" ".*" ".*"
관리화면 플러그인 활성화
$  sudo rabbitmq-plugins enable rabbitmq_management
재시작
$ sudo service rabbitmq-service restart

접속 (서버주소)
http://localhost:15672

 

Redis

$ sudo apt install redis-sentinel  redis-server    redis-tools
$ sudo nano /etc/redis/redis.conf
------
# bind 192.168.1.100 10.0.0.1
#bind 127.0.0.1
bind *
------

$ sudo service redis-server restart

sentinel 관련 설정은 클러스터링테스트시..

 

 

 

Dokku 장단점 간략

개요

이름처럼 Docker기반으로 동작하는 소형 배포시스템이다.

미니 헤로쿠(Heroku)라고 하는데

Heroku를 써본적이 없으니 미닌지 빅인지 뭐 알수가 없다.

헤로쿠가 빌드배포가 그렇게 편리하다며?

도쿠는 그 컨셉을 따라서 만든 오픈소스

Github : https://github.com/dokku/dokku

Homepage : http://dokku.viewdocs.io/dokku/

간략사용법

설치

설치는 홈페이지에 써있는 스크립트를 그대로 실행시키면 된다

$ wget https://raw.githubusercontent.com/dokku/dokku/v0.10.3/bootstrap.sh
$ sudo DOKKU_TAG=v0.10.3 bash bootstrap.sh

이렇게 하면 docker, nginx설치 + dokku계정이 생성된다.

이제 80포트와 docker는 따로 손대지 않는게 좋다.

Dokku를 쓴다면 아마 Cloud Instance를 쓸 것 같으니 별 문제없을 것 같은데…
서버에 설치해서 쓰는 경우에는 리눅스 서버관리에 익숙하지 않다면 dokku가 설치된 서버는 단독으로 사용하는게 좋다.

도메인 연결

두가지를 등록 해 줘야한다.

dokku.polypia.net : 도커 GIT-SSH 접속주소 겸 초기 홈페이지 설치주소

*.dokku.polypia.net : 도쿠 배포된 프로젝트 주소가 된다.

예를들어 webwww라는 앱을 다음 주소로 푸시를 한다면 dokku@dokku.polypia.net:webwww

webwww.dokku.polypia.net 이 주소가 된다.

GIT 사용자 추가

/home/dokku/.ssh 에 public key를 등록 해 줘야하는데

일반적인 키 등록하는 것과는 다르다.

(등록과 동시에 스크립트가 실행되는 방식)

이 부분이 좀 헷갈리는 부분인데… 홈페이지 구석에 숨어있어서 찾기가 좀 힘들다.

http://dokku.viewdocs.io/dokku/deployment/user-management/

ssh-keys:add <name> [/path/to/key]             # Add a new public key by pipe or path
ssh-keys:list                                  # List of all authorized Dokku public ssh keys
ssh-keys:remove <name>                         # Remove SSH public key by name

public key를 올려놓고

dokku ssh-keys:add KEY_NAME_USERNAME id_rsa.pub

배포

http://dokku.viewdocs.io/dokku/deployment/application-deployment/

앱생성

dokku apps:create webwww

환경변수 등록

프로파일 관리를 할 때는 서버별로 변수를 등록해주는게 좋다.

배포할 때 소스에 박아서 넣을수는 없잖아

http://dokku.viewdocs.io/dokku/configuration/environment-variables/

dokku config:set webwww spring.profiles.active=prod COMPILE_ASSETS=1

이렇게 하고나면 /home/dokku/webwww/ENV 파일에 환경변수가 추가된다.
export spring.profiles.active=prod
SPRING_PROFILES_ACTIVE=prod
일지도 모른다. 두개 다 등록해놔서.. .확인해보고 안되는걸 지워야되는데

GIT PUSH

아까 등록해놓은 git 주소로 push하면된다.

git push dokku master

정도가 될까…

위에서 create를 먼저 한 것은 환경변수(서버프로파일)을 등록하려고 먼저한건데 create를 꼭 먼저 해야하는건 아니다. 그냥 소스코드 업로드하면 리포지터리가 생성+앱추가+빌드가 자동으로 된다.

장단어이없는점

설치가 쉽고 쓰기도 쉽?다? 도큐먼트가 튜토리얼 형태로 작성된게 의외로 별로 없어서… 생각처럼 간단하지는 않다.

설계 사상이 직관적으로 이해가 가면 괜찮은데… 그렇지도 않아서 어떻게 써야할지 바로 떠오르질 안는게 문제

git listen방식이 아닌 직접 push방식만을 지원하는건가? 좀 복잡하게 하면 설정도 가능할 것 같은데…

인터페이스 화면이 없다. 일단 화면이 없으면 쓰기가 어렵다. 도큐먼트를 무조건 들여다 봐야하니까… dokku도 일단 개발외적인 부분으로 이런거 설정하는데 시간낭비를 하게된다면… 손해 아닌가

build 이미지와 deploy 이미지가 분리되면 좋을텐데… build 이미지가 그대로 사용되는 것 같다. 그래서 이미지 용량이 1기가…

Dockerfile을 사용하려면 또 이런저런 설정을 해줘야하는건가? 내가 셋팅해놓은 Dockerfile을이 제대로 안돌아가는 것 같다. 뭔가를 덮어씌우는건지

사용후기

 

여러가지 솔루션 오픈소스를 보면서 느낀건데 잘 만들어진 솔루션은 군더더기가 없었고 머리를 짜내서 고민을 해도 정말 최선?최적?의 방법으로 구현되었다는 생각이 든다.
이렇게 설계가 잘 된 솔루션을 사용하면 필요한 기능이 있을 때 그것을 찾기가 쉽다. 당연한 방법으로 설계가 되어 있으니까

1등급 SpringFramework, WordPress, Docker, docker-compose, vagrant, Angular, VirtualBox, Netty,

2등급 chef,

딱 생각은 안나는데 대강 이정도…

 

Docker가 익숙하다면 docker-compose와 스크립트를 이용한 배포가 더 낫지 않나 싶다.

그닥 좋은지 모르겠다.

아니면 그냥 Heroku를 쓰던가

 

Dokku에서 이런저런 기능이 많이 지원되는 것 같은데…

심플함은 놓치고 있는 것 같다.

애초에 복잡한 서비스를 하라고 만든 컨셉이 아니었을텐데

복잡한 인프라 구성을 할것같으면 docker-swarm이나 kubernetes를 쓰지 않을까

Provisioning Tool

Chef
Vagrant
Puppet
Ansible

https://cloud.google.com/solutions/google-compute-engine-management-puppet-chef-salt-ansible

https://brunch.co.kr/@jiseon3169ubie/2

https://xebialabs.com/the-ultimate-devops-tool-chest/provisioning-config-management/

웹개발시 인프라 구성

다음과 같이 환경을 구성하고
여기에 맞춰서 devops 구성을 하면 된다.

1. dev

개발환경
Vagrant, Docker등 활용해서 환경구성

1-1 dev-local

각자 DB, MQ 구동

1-2 dev-remote

동일 DB, MQ 구동

2. real

idc, cloud 환경

2-1 real-stage

product 배포전 테스트
확인 후 인스턴스 종료

2-2 real-product

product실제서버 batch인스턴스 이외에는 항상동작