별 볼일있는 공간

CloudFoundry 기반 PaaS 플랫폼 배포를 진행 하면서 모은 자료를 하나하나 정리하려고 합니다 

Why PaaS

o Cloud 환경으로의 IT Infra(Compute/Storage/Network)의 Shift

o IaaS 넘어 개발 환경 및 서비스 플랫폼까지 제공/관리 PaaS 등장

o 신속한 Business를 위한 Application 중심의 Cloud Infra 필요 대두

CloudFoundry

o Open source PaaS platform

o 어플리케이션의 배포/운영을 간소화하기 위한 PaaS Platform

Capability

o Abstraction(추상화,CPI)

• 폭 넓은 Infrastructure 선택(IaaS 독립적)
• 실행되는 언어/프래임워크에 중립적(자유도)

o Automation(Bosh)

• Automated Virtual Infrastructure를 통한 Application의 중앙 대규모 설치/관리/운영
• 큰 규모의 Application의 배포, 실행이 수월

o Scalability(확장성)

• 각 컴포넌트들이 독립적으로 구성 -> 빠른 확장성에 용이

Effect

o Application Platform 및 관리시스템 도입

• Cloud 환경에서의 애플리케이션을 효율적으로 개발·배포·관리(CICD)

o 빠른 인프라 확장성

• 개발 환경의 Re-build 없이 손쉬운 어플리케이션 배포

o 개발자의 요구 만족

• VM Provisioing의 목적이 아닌 Application 개발의 Focus -> 프로젝트의 생명주기 동안 반복적인 개발/배포

# bind9 설치

아래 config file 수정

# cat named.conf.options <-------- forward 옵션 설정 , dns 서버에 없는 경우

forwarders {

8.8.8.8;

};

# cat named.conf.local <-------- zone 생성(domain 등록)

zone "wlstn.com" {

type master;

file "/etc/bind/db.wlstn.com";

};

# cat db.wlstn.com

root@ubuntu:/etc/bind# cat db.wlstn.com 

;

; BIND data file for local loopback interface

;

$TTL 604800

@ IN SOA ns.wlstn.com. root.wlstn.com. (

     2 ; Serial

604800 ; Refresh

 86400 ; Retry

2419200 ; Expire

604800 ) ; Negative Cache TTL

;

@ IN NS ns.wlstn.com.

@ IN A 192.168.218.129

www IN A 192.168.218.130

mail IN A 192.168.218.131

* IN A 192.168.218.129

iptables 간단하게 정리하고 자주쓰이는 기능에 대해서 정리하고자 한다

크게 2가지 filter, nat table이 존재함

각 table에는 아래와 같은 Chain 룰셋이 있다

1) input

2) forward - filter table에만 존재

3) output 

4) nat(PREROUTING, POSTROUTING) - nat table에만 존재

옵션은 2가지만 알자 

-A (Add) - rule 추가

-D (Del) - rule 삭제

[사용법]

1) iptables 읽기

# iptables -L : 리눅스 iptable은 기본으로 filter table을 읽음

# iptables -t nat -L : nat table 읽음 

2) iptables 삭제

# iptables -F

[예제]

1) Linux OS에서 출처 input chain 제어

# iptables -A input -j DROP - 모든 input 패킷 드랍

# iptables -A input -s 192.168.100.100 -j DROP - 출발지가 192.168.100.100인 패킷 드랍

# iptables -A input -d 192.168.100.100 -j DROP - 목적지가 192.168.100.100 패킷 드랍

# iptables -A input -p TCP -j ACCEPT - TCP 프로토콜 쓰는 패킷 허용

# iptables -A input -p TCP --dport 80 -j DROP - TCP 80포트로 목적지로 사용하는 패킷 DROP

# iptables -A input -i eth0 -p TCP --dport 80 -j DROP - eth0 TCP 80포트로 목적지를 사용하는 패킷 DROP 

여기서 참고로 인터페이스 옵션은 input chain은 -i 만 output chain은 -o 만 옵션만 사용 가능함 

Masqurade 

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE 

sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

사용법 : iptables

테이블(filter, nat, mangle, raw)

체인(INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING)

룰설정 : -A : append , -l : insert , -D : 룰 삭제 , -F : 해당 Chain 모든 룰 삭제, -R: replace 룰 치환

           -p : 프로토콜(tcp,udp,icmp), -s 출발지 , -d 목적지 , --sport 출발지 포트, -dport 목적지 포트 -i 입력인터페이스, -o 출력 인터페이스

정책지정 : -j 옵션을 통해서 타겟 체인 설정(ACCEPT, DROP(차단), REJECT(차단하면서 ICMP 응답 전송), LOG)

iptables -t nat -A PREROUTING -p tcp -d 10.13.31.91 --dport 80 -j DNAT --to 10.244.0.34:80

iptables -t nat -A PREROUTING -p tcp -d 10.13.31.91 --dport 443 -j DNAT –to 10.244.0.34:443

iptables -t nat -A PREROUTING -p tcp -d $INTERNAL_IP --dport 4443 -j DNAT –to 10.244.0.34:4443

iptables -t nat -A PREROUTING -p tcp -d 10.13.31.91 --dport 8022 -j DNAT --to 10.244.0.34:22

iptables -t nat -A PREROUTING -i eth1 -p tcp -d 10.13.31.91 --dport 8022 -j DNAT --to 10.244.0.34:22

iptables -A FORWARD -p tcp -i eth1 -d 10.13.31.91 --dport 8022 -j ACCEPT

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

리눅스 user라면 반드시 사용하는 find, grep 

매번 해당 명령어의 옵션이 기억이 가물가물 ...

o find 

find 경로 옵션 조건 action

여기서 옵션은  -name , -user, -perm, -type 등이 사용

action 에서는 -exec 사용, 예제에서 보듯 결과값이 {}으로 들어감, "\;" <-- 요건 관례적으로 사용하는 필수 구문

example)

# find ./ -name *.py

# find ./ -name *.py -exec rm -f {} \;

# find ./ -type f

o grep

요약해서 파일내의 패턴 검색 후 일치하는 패턴 출력

grep linux /etc/*

python 에서의 continue, pass, break 를 정리해보자

for element in some_list: 
    if not element: 
        pass 

for element in some_list: 
    if not element: 
        continue

3문장으로 요약하자면  
1) pass는 단순히 실행할 코드가 없다는 것을 의미한다
2) continue는 다음 순번의 loop를 돌도록 강제하는 것을 의미

3) 이둘은 명백히 다른 구문이다, pass 와는 다르게 continue는 바로 다음 순번의 loop를 돈다

만약 pass 를 타게 되면 A작업은 수행되지만, continue에서는 수행되지 않고 바로 다음 loop 순번으로 돈다.

############################
예제)

for i in [1,2,3]:
        if i:
                print "pass %d" % i
                pass
        print "mjsjinsu pass" # will print after pass


for i in [4,5,6]:
        if i:
                print "pass %d" % i
                continue
        print "mjsjinsu continue"

############################
실행 결과 )

pass 1
mjsjinsu pass
pass 2
mjsjinsu pass
pass 3
mjsjinsu pass
pass 4
pass 5
pass 6

python Class와 self에 대한 변수 namespace에 대한 내용

Class를 선언하고 변수 초기화에 대한 __init__ 함수의 역할

 - 보이지 않게 Class 객체 생성/소멸 시 __init__/__del__ 통해 초기화/소멸 과정 거침

 - self 라는 지시자는 객체 생성 시 자신의 객체 자체를 가르키는 역할

예제에서 self = show_self와 같다는 의미

class MyClass():

def __init__(self, x, y):

self.x = x

self.y = y

def show_self(self, z):

y = 3 

print "I am self var x = {0}".format(self.x)

print "I am self var y = {0}".format(self.y)

print "I am def var y = {0}".format(y)

print "def param var z = {0}".format(z)

if __name__ == '__main__':

i = MyClass(1,2)

i.show_self(4)

Foundry : 주문생산공장

다른 업체가 설계한 반도체를, 즉 주문에 의해 반도체 칩을 생산해서 공급해 주는 사업/제조업체

1) 주문 생산 공장 중에는 여유 있는 제조 능력을 활용하여 다른 업체의 주문을 받아 반도체 제품을 제조하는 대규모 제조업체

chef-zero—a simple, in-memory version of the Chef serverprovided by Chef DK—when converging the local workstation.

chef-client -z -o cookbook

chef-client -z -o chef-zero

옵션 설명 : -z(chef-zero) -o (recipe override)

chef workstation에서 chef-server 없이 local 모드로 cookbook를 적용할 수 있는 옵션이다

chef 서버 없이 간단히 적용할 수 있는 장점이 있음

chef-zero는 chef-client 구동 이후에 json 파일형식으로 node 디렉토리에 node에 대한 attributes 파일을 생성한다(참고)

knife를 이용해 node 및 client 삭제 시 ... 2번 지워야 되는 불편함 있음

knife node delete chef-client02

knife client delete chef-client02

chef-dk에서 제공하는 gem 을 통해 knife-pg 플로그인을 받아 

# chef gem install knife-playground

# knife pg clientnode delete chef-client02

한번에 삭제 가능!!!

Berkshelf : 요약하자면 managing cookbook dependencies 

Berkshelf는 의존성 있는 cookbook들은 모두 다운로드?(실제로 실제 쿡북의 로컬 저장 위치는 /root/.berkshelf/cookbooks)하고 chef-server에 cookbook upload 시 유용하다

Berksfile이라는 dependencies 파일에 의해 의존성 check를 함

metadata.rb에 dependencies cookbook을 기재하고...recipe file에 include_recipe 하면

berks install 시 의존성 cookbook 을 설치

[root@chef-mjs study]# berks install

Resolving cookbook dependencies...

Fetching 'study' from source at .

Fetching cookbook index from https://supermarket.chef.io...

Installing chef-client (4.3.1)

Installing chef_handler (1.2.0)

Installing cron (1.6.1)

Installing logrotate (1.9.2)

Installing ntp (1.8.6)

Using study (0.1.0) from source at .

Installing windows (1.38.1)

cookbook 의존성 관련 Berksfile.lock 파일 만들어짐

[root@chef-mjs study]# cat Berksfile.lock 

DEPENDENCIES

  study

    path: .

    metadata: true

GRAPH

  chef-client (4.3.1)

    cron (>= 1.2.0)

    logrotate (>= 1.2.0)

    windows (~> 1.37)

  chef_handler (1.2.0)

  cron (1.6.1)

  logrotate (1.9.2)

  ntp (1.8.6)

  study (0.1.0)

    chef-client (>= 0.0.0)

    ntp (>= 0.0.0)

  windows (1.38.1)

    chef_handler (>= 0.0.0)

berks upload 시 의존성 cookbook upload

[root@chef-mjs study]# berks upload --no-ssl-verify

Uploaded chef-client (4.3.1) to: 'https://chef-mjs:443/'

Uploaded chef_handler (1.2.0) to: 'https://chef-mjs:443/'

Uploaded cron (1.6.1) to: 'https://chef-mjs:443/'

Uploaded logrotate (1.9.2) to: 'https://chef-mjs:443/'

Uploaded ntp (1.8.6) to: 'https://chef-mjs:443/'

Uploaded study (0.1.0) to: 'https://chef-mjs:443/'

Uploaded windows (1.38.1) to: 'https://chef-mjs:443/'