Category Archives: Infra

Serverless Framework 선택

serverless
https://serverless.com/cli/
https://github.com/serverless/serverless

zappa

zpex

AWS sam

Spring cloud function
https://medium.com/faun/spring-cloud-function-deploy-first-serverless-function-using-spring-1bbdc0a4620d

인프라

AWS Lambda

GCP cloud function
https://cloud.google.com/functions/

Knative
https://github.com/triggermesh/knative-lambda-runtime
https://about.gitlab.com/product/serverless/
https://labs.sogeti.com/knative-introduction-to-a-native-serverless-platform/

참고

IaC, Infra as Code – 인프라를 코드로 관리

클라우드로 넘어오면서 관심이 커진 분야

서버 프로비저닝 기술

  • Chef
  • Ansible
    클라이언트에 에이전트 설치 없이 원격으로 설치를 해 준다는 장점
  • Puppet
  • Saltstack
  • Packer
  • Groovy Infrastructure

요즘은 잘 안쓰는 설치 프로비저닝

SE를 안해봐서 모르겠지만.. 서버관리 하는 사람들은 이런거 USB 만들어서 들고다니지 않았을까
https://www.cyberciti.biz/tips/server-provisioning-software.html

  • Kickstart
  • FAI, Fully Automatic Installation
  • Cobbler
  • Spacewalk
  • OpenQRM
  • Foreman

클라우드 코드화(설정)

  • AWC Cloud Formation
    이건 그냥은 거의 못쓴다고 보면 된다
    AWS CDK를 활용
  • GCP – yaml
    따로 이름도 없는 것 같은데 구조가 잘 잡혀있어서 읽기 쉽고 재활용도 쉽다
  • Terraform
    클라우드 서버 인프라 뿐 아니라.. 여러가지 provider를 사용하면 github 설정도 코드화할 수 있다
  • 기타 ansible, chef 등에서 제공하는것들.. 플러그인 형태로 추가하면 되는 것 같은데 주류는 아닌 듯 싶다

클라우드 코드화(SDK)

  • AWS CDK
  • python boto
  • aws-sdk-rails

~

개인적으로 DSL형태의 설정을 좋아해서
Ruby계열 언어를 사용하는 프로그램이 많아지면 좋겠는데
대세는 yaml이나 파이썬 코드인 것 같다

람다는 쉽다며 씨발

개삽질 기간포함 일주일 좀 넘게 걸린 것 같다.

1단계 Go로 HelloWorld

처음엔 go언어 이용해서 간단하게

2단계 외부연동 GW

GW설정을 해야되는군… 뭐가 씨발 되다말다 하고
DTO구성을 바꿔줬다

3단계 RDS 연결

같은 VPC를 써야하는군..
iam인증을 쓰면 커넥션 생성속도가 느리다고?
타임아웃은 왜 계속 나오는거지
vpc에서 시큐디티 그룹을 연결시켜줘야 하는군
아이피는 왜 자꾸 변하는데… vpc전역(172.1.0.0/16)을 오픈 해 놔야하는건가
커넥션 풀은 어떻게 하지? 일단 패스

4단계 SNS 호출

제대로 한 것 가튼데
로컬에서 호출이 되는데
아 왜 안되지
머리가 마비된다
event trigget – sns to lambda는 많은데 lambda to sns자료는 잘 없다.
엔드포인트 생성(https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpce-interface.html)
(https://docs.aws.amazon.com/ko_kr/sns/latest/dg/sns-vpc-endpoint.html)

셋팅하고나서 좀 있으면… 된다.

Object Storage 비교 – minio, ceph …

용도

예전에는 서버를 여러개 띄우면 /upload 경로에 nas를 마운트해서 사용했을거다.
요즘은 앱 배포시 서버리스나 컨테이너를 많이 사용하면서 서버에 직접 파일을 업로드 하는경우가 더 없어져서 스토리지를 별도로 사용해야 한다.

덤으로 대용량 로그파일도 저장하고 빅데이터 분석플랫폼에서 쉽게 가져와서 돌릴 수도 있다.

종류

  • 설치형
    • minio
      (https://www.minio.io)
    • ceph
      (https://ceph.com)
    • Red Hat OpenShift
      (https://www.redhat.com/ko/technologies/cloud-computing/openshift-container-storage)
    • HDFS
      하둡 파일시스템
    • infinit storage
      ??망했나
  • 클라우드 On demand
    • gcs(Google Cloud Storage)
    • aws(s3)

용도도 각각 다르고 성능도 다르고 해서 아무데나 막 쓸 수는 없다.
대강 써도 어느정도 성능은 나오긴 할텐데
아직 기술이 초기라서 그런지 딱히 좋은 자료가 안 보인다.

선택

minio, ceph 중에 하나를 쓸 것 같다.
성능이야 다 개선되고 있는 중이고 서로 다 좋다고 하니 써 봐야 알 것 같다.
일단 쓰기 편한건 두가지다.
용도는

  • 로그파일 저장
  • 이미지 업로드, 파일업로드 백엔드

minio는 설치가 편하다. docker 기반으로 실행도 가능.
ceph는 엔터프라이즈 서비스에서도 적용사례가 있는 것 같다. 설치는 조금 더 복잡할 것 같다.

어차피 개발중이니 minio를 먼저 써 보고 문제가 생기면 검토 해 보는걸로

Ubuntu18.04 Bionic Beaver HDD Mount 하드 추가

파티션 잡기

parted 이용
(참고) 

https://blog.hqcodeshop.fi/archives/273-GNU-Parted-Solving-the-dreaded-The-resulting-partition-is-not-properly-aligned-for-best-performance.html
$ sudo fdisk -l
~~~파티션 정보 확인

파티션 잡는 프로그램 기본으로 안 깔려있으니 설치
$ sudo apt install parted

$ sudo parted /dev/sdb
~~~
(parted) mktable gpt
(parted) mkpart
ext4
0%
100%

포맷

http://mhugt.tistory.com/47
http://noota.tistory.com/entry/%EC%9E%90%EB%8F%99-%EB%A7%88%EC%9A%B4%ED%8A%B8-%EB%B6%80%ED%8C%85-%EC%8B%9C-%EC%9B%90%ED%95%98%EB%8A%94-%ED%95%98%EB%93%9C%EB%94%94%EC%8A%A4%ED%81%AC-%EC%9E%90%EB%8F%99%EC%9C%BC%EB%A1%9C-%EB%A7%88%EC%9A%B4%ED%8A%B8-%EB%90%98%EB%8F%84%EB%A1%9D-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0

$ sudo mkfs.ext4 /dev/sdb1
$ mkdir tmpdir
$ sudo mount /dev/sdb1 /tmpdir

자동 마운트

uuid 확인

$ sudo blkid
$ ll /etc/disk/by-uuid
$ nano /etc/fstab

맨뒷줄에 추가
UUID=xxxxxxxxxxxxxxxxxxxxxxuuidxxxxx /tmpdir ext4 defaults 0 0

tmpdir을 원하는 경로로 변경

마운트 테스트

$ sudo mount -fav

Iaas, Provisioning tool – Chef, Ansible, Puppet, Rex, Provy, Fabric

서버 프로비저닝 툴

최근 컨테이너(도커)와 Serverless 사용으로 서버 프로비저닝은 중요도가 좀 떨어지긴 했는데
PC, 로컬서버, 개별인스턴스 초기구성할 때 아쉬운 경우가 종종있다.

예전엔 chef가 대세였는데…
그냥 관련 기술 자체에 대한 관심이 죽은건지 이 회사가 폐쇄적인 정책으로 변해서 그런건지 커뮤니티에서 언급이 상당히 줄었다.

Chef

https://github.com/chef/chef
rails 베이스
성능도 강력하고 지원되는 것도 많은데
도구가 너무 난잡하게 이것저것 많다.
chefck chefsolo chefzero chefclient chefserver, berks… 개념정의나 각 모듈의 영역이 명확하지 않아서 헷갈린다.
억지로 찾아서 쓰면 쓰는데… 커뮤니티가 상당히 죽은 것 같다.
(무리한 유료화, 컨테이너 이후 비주류 기술로전락..등)
2017년 이후 각종 커뮤니티에서 언급조차 거의 안되고 있다.

Puppet

https://github.com/puppetlabs/puppet
python 베이스
chef랑 비슷한 것 같은데 그래도 상황이 좀 낫지 않나 싶다.

Ansible

https://github.com/ansible/ansible
설정 베이스
배우기 쉬워서 쉽게 접근해서 쓰는 것 같다.

Saltstack

https://github.com/saltstack/salt
이게 제일 많이 쓰이는 것 아닌가 싶다.
새로 하려면 이걸로

Fabric

http://www.fabfile.org/
툴이라기보다는 python ssh 라이브러리.
이걸 베이스로 개발된 툴들이 좀 있는 것 같다.

Rex

https://github.com/RexOps/Rex
오픈소스.
perl 기반 툴
perl까지 해야되나…

## Provy
http://heynemann.github.io/provy/
오픈소스.
파이썬 기반

Tiamet

Python기반 클라우드 프로비저닝 툴
https://github.com/HardBoiledSmith/tiamat
https://github.com/HardBoiledSmith/johanna

Infrastructor

http://infrastructor.io/
groovy 베이스
안써봤지만 괜찮을 것 같다.
dsl형태도 제공되고

# ~
뭘 쓸지 아직 결론을 내진 못했는데..
조금이라도 써본 chef
익숙한 groovy, python 베이스 툴을 쓰게될 것 같다.

#~ 그냥 손으로 할까
인프라쪽은 본업도 아닌데 너무 많이 시간을 잡아먹는다.

Serverless Architcture 적용 – 기술조사

올해의 핫 키워드 서버리스 아키텍처

갑자기 떠올랐다고 해야되나.. 내가 갑자기 알게된건가

AWS서밋2018 가서 보고 이게 이렇게 핫한 기술이라는걸 알게 됐다.

컨테이너 기반 개발/배포에 어느정도 익숙해져 갈 즈음이라… 이게 왜 필요한지 잘 이해가 안 갔었달까
(뭐 그냥 로그수집 할 때나 쓰면 적당하겠군)

그런데 최근 파일업로드 서버를 만들다가 갑자기 생각이 들었다.

여기다가 쓰면 되는거구나…

한번 생각나고 나니까 여기저기 적용할만한 구석이 보이기 시작한다.

개발환경

테스트 없이 배포까지 한 번에 할 수 있는 사람이 있긴할까?

역시 테스트가 필수적이다. 실서버에 배포를 하면 시간도 오래 걸리고, 돈도 들고, 운영중인 서비스라면 서비스가 중단된다.

로컬에서 빠르게 코딩-테스트할 환경이 필요한데

AWS, GCP 모두 테스트 환경을 제공 해 주고 있다.

로컬에 설치해서 개발이 가능한 솔루션도 많이 있다. 집에다가 한개 설치 해 놓고 개발용으로 써도 될 것 같다.

서버리스 솔루션

https://github.com/kubeless/kubeless

Home Page


https://www.openfaas.com/
https://openwhisk.apache.org/

FAAS

AWS는 다양한 언어를 제공 해 주고 있는 데 반해.
GCP는 아직 걸음마 단계… js만 사용가능하다.

kubernets 기반에 설치해서 사용이 가능한 fission도 있고
다른 서버리스 솔루션들을 kubernetes에 설치해서 써도 될 것 같지만….
그럴거면 그냥 컨테이너를 띄우지…

Serverless가 간편하다고 하지만.. SpringBoot나 다른기술들에 어느정도 익숙하다면 시간차이는 크지 않다.
AWS를 쓰면 구축 난이도가 좀 높은 API게이트웨이까지 사용할 수 있어서 더 좋을 것 같다.
AWS의존적인 시스템을 만들지 않으려고 했지만.. 이건 뭐 답이 없다. 그냥 의존적으로 가다가 문제가 생기면 빼는게 나을 것 같다.

로컬테스트는 이것저것 해보겠지만… 실 서비스는 AWS, API Gateway, DynamoDB/Aurora가 거의 확정.

PowerShell 명령어로 윈도우 환경변수Env 관리

Registry에서 환경변수의 경로

# 사용자 환경
HKEY_CURRENT_USER\Environment
# 시스템 환경
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

‘Path’에 gradle 경로 append

$oldPath=(Get-ItemProperty -Path 'Registry::HKEY_CURRENT_USER\Environment' -Name PATH).Path
$newPath = $oldPath+ ';%USER_PROFILE%\scoop\apps\gradle\current\bin'
Set-ItemProperty -Path 'Registry::HKEY_CURRENT_USER\Environment' -Name PATH –Value $newPath

Gradle HOME 추가

Set-ItemProperty -Path 'Registry::HKEY_CURRENT_USER\Environment' -Name GRADLE_HOME –Value '%USER_PROFILE%\scoop\apps\gradle\current'

 

뽀너스

자주 쓰는 명령

$env:UserName
$env:UserDomain
$env:ComputerName

[Mac] Mac 패키지 관리 툴 – Homebrew + Cask

Homebrew

[공식 사이트](https://brew.sh/index_ko.html)

예전에는 Mac에서 패키지관리를 할 때 MacPort를 많이 썼는데
요새는 Homebrew진영에 주도권을 넘겨준 모양새다.

Port는 소스코드를 받아서 컴파일 후 설치를 하는데 Brew는 미리 컴파일된 파일을 다운받아 바로 설치를 하니 속도가 빠르고 오류가 적다.

설치 방법

스크립트

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

사용법

# 패키지 설치
brew install wget
brew install {packagename}
# 패키지 검색
brew search mysql

Homebrew Cask

[공식 사이트](https://caskroom.github.io)

기존의 Homebrew가 라이브러리, 데몬 설치에 사용됐다면
Cask는 유틸리티 설치에도 사용된다

사용법

# 설치
$ brew cask install google-chrome
$ brew cask install inkscape
# 검색
$ brew cask search visual

검색은 공식사이트에서 해도 된다

https://caskroom.github.io/search

사용후기

cask 설치 실패가 나는 경우도 종종 있다.

환경때문에 그런 것 같지는 않고 자주 안 쓰는 패키지는 관리가 안되는 경우가 종종 있는 것 같다.

공식앱스토어가 아닌 이런곳에서 패키지를 설치하는게 보안상 안좋을 수도 있을 것 같다. 리포지터리나 dns가 해킹당하는 경우 아니면 패키지에 바이러스를 심어서 배포하는 경우에는 위험할 수도 있다.

괜찮겠지?