Programmer 2016 ~

환경은

NIC1 외부망 IP 61.xx.xx.xx, 내부 망 10.8.0.1

NIC2 내부망 172.xx.xx.x을 사용 하여

Openstack(NIC2 172.xx.xx.x) 서버를 구축되었고 NIC1외부망에 Openvpn 서버를 설정하여 외부에서 클라이언트가 접근 가능하도록 VPN 망을 구성 하였다.

설치 및 환경이 완료 되었고 Openstack 서버에서 리소스 생성 및 VM 생성 테스트 까지 진행 하였다.

테스트가 끝나고 Jenkins 및 SCM 서버를 설치 중 Jenkins 서버에서 WEB Plugin이 다운로드 안되는 현상이 발견 되었다.

Jenkins 서버에 ssh 접속 하여 ping을 확인 한 결과 내부 끼리 통신은 되는데 외부 끼리 통신이 안된다는 문제점이 발견 되었다.

VPN 서버는 접속이 되었지만 내부 VM에서 외부로 ping이 나가려고 하면

10.8.0.1 아이피에 대하여 iptable 및 port forwarding이 필요한 것 같다.

설정 방법은

# tunneling

$ iptables -I FORWARD 1 --source 10.8.0.0/24 -j ACCEPT 

$ iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE 

# port forwarding

$ sudo iptables -t nat -A POSTROUTING -o em2 -j MASQUERADE

$ sudo iptables -A FORWARD -i em2 -o em3 -m state --state RELATED,ESTABLISHED -j ACCEPT

$ sudo iptables -A FORWARD -i em3 -o em2 -j ACCEPT

을 실행 시켜 VM 내부에서 ping이 외부로 나가 도록 구성 하였다.

AWS 환경에서 CF & Diego 설치 후 

$ cf login 후에 Java Sample App을 push 중

Java 런타임 환경의 BuildPack을 업로드 하지 못하는 에러가 발생 했다. 에러 메세지의 로그는 아래와 같았다.

2018-02-22T17:18:49.86+0900 [STG/0]      ERR [DownloadCache]                  WARN  Unable to download https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/index.yml into cache /tmp: execution expired

2018-02-22T17:18:49.86+0900 [STG/0]      ERR [Buildpack]                      ERROR Compile failed with exception #<RuntimeError: Open JDK Like Memory Calculator error: Unable to find cached file for https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/index.yml>

2018-02-22T17:18:49.86+0900 [STG/0]      ERR Open JDK Like Memory Calculator error: Unable to find cached file for https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/index.yml

2018-02-22T17:18:49.86+0900 [STG/0]      ERR Failed to compile droplet: Failed to compile droplet: exit status 1

Show less

구글링 하던 중 해당 에러에 관련하여 offline java buildpack을 사용 가이드가 나와 있어 offline java buildpack을 다운로드 하여 재실행 하였는데 같은 에러 메세지가 발생 하였다.

CF_TRACE log를 확인하여 보니 443 HTTPS  통신 중 500 Staging error와 diego와 통신이 안된다는 에러를 발견 할 수 있었다.

성공적으로 CF & Diego는 설치 완료 했지만 CF에서 cf-cli 명령어를 받는 Cloud Controller에서 Diego로 통신을 할 수 없는 문제 인것 같았다.

에러를 해결 하며 알게 된 점이

다른 인프라 환경과는 다르게 AWS는 Public Subnet과 Private Subnet이 나누어져 있으며 

Pubilc Subnet은 Elastic IP를 할당 한 VM이 있고 Router Table이 Internetgateway와 연결이 되어 있어야 한다.

Private Subnet은 내부 아이피를 할당 한 VM이 있고 Router Table에 별도의 Natgateway를 연결 하여 내부적으로 Nat 통신이 가능하도록 구성을 하여야한다.

아래는 기존의 Cloud foundry 설치 방법이 였고 위에 문제 떄문에 아키텍쳐를 변경 하였다.

아키텍쳐를 변경하고서 다른 문제점이 발생 할 가능성이 있다.

아래는 변경 한 Cloud foundy의 아키텍처 참고 이미지다.

bosh, cf를 public subnet

diego를 private subnet 으로 구성하고 nat gateway를 생성하여 연결 했다.

해당 이슈가 발생하면서 발견 한 이슈는 AWS로 VM 생성 시 EBS로 volum이 Attach 되는 것 같은데 Root disk의 용량을 늘려주려면 어떻게 하는지 모르겠다..

Cloud foundry에서는 각 컴포넌트 별로 통신을 하기 위해 Open SSL 기반의 인증서를 사용 한다.

현재 나의 자바 소스에서는 Progresbuilder를 통해 certstrap이라는 자동 스크립트 파일을 바탕으로 Open SSL 기반의 인증서를 여러개 생성하고 키 값에 맞춰 필요한 컴포넌트에 인증서를 맵핑 시킨다.

로컬에서는 문제 없이 돌아가지만 클라우드 환경의 서버에서 자바 패키지를 빌드하고 자바 패키지에 필요한 소프트웨어를 설치 하기 위해 자동 스크립트를 만들어 사용 중이다.

certstrap이 돌아가기 위해서 gopath 지정이 반드시 필요 한대, 현재는 gopath를 지정한 파일을 생성하여 리눅스 파일 시스템 /etc/profile.d/ 에 옮겨 놓고 작업을 하였다.

서버가 재부팅 및 off/on 하였을 경우 해당 gopath가 날라가는 에러가 발생 하였다.

리눅스 환경에서 환경 변수를 읽는 시점 및 gopath의 특정한 문법 등을 찾아 보았지만 원인을 찾지 못하여 자바 톰켓 서버가 실행 되는 순간 gopath를 지정하여 읽고 들어가게 만드는 방법을 임시 방편으로 쓰던 중  /etc/profile.d/에 들어간 gopath 지정 파일이 실행 파일이 아닌것을 확인 하였고, 실행 파일 권한을 부여하고 재실행하였더니 문제가 사라졌다.

cloud foundry 배포 중  is not running after update. Review logs for failed jobs: route_registrar  에러가 발생 하고 배포가 실패 할 경우

ssh 접속을 통해 해당 blob 컴포넌트가 컴파일 된 서버에 접속 한다.

1. ping 8.8.8.8을 하여 외부와 통신이 가능 한지

2. ping 내부 서브넷 아이피 및 dhcp와 통신하여 내부와 통신이 가능 한지 확인 하였을 때 이상이 없었다.

로그 파일의 문구는 아래와 같다.

위의 문제점은 cloud foundry 배포 시 설정 파일에서 domain 주소를 잘 못 입력하여 API 통신 시 할당 되는 API endpoint에 접근이 불가능 하여 발생 한 에러인 것 같다.

자바 multipart로 파일을 업로드 중 아래와 같은 이슈가 발생 하였음.

threw exception [Request processing failed; 

nested exception is org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is java.io.IOException: org.apache.tomcat.util.http.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. null] with root cause

java.net.SocketTimeoutException: null

해당 에러에 관련하여 아래의 방법으로 추측 하여 어떤 상황일떄 에러가 발생하는지 확인하여 보았다.

1. 서버에 용량의 꽉 찾을 경우

     No Space device 라는 에러 문구가 발생 한다.

2. 한번에 여러개의 파일을 올리거나 용량이 큰 파일을 올렸을 경우

     maxFileSize: 5000KB

     maxRequestSize: 5000KB 나의 환경은 설정 되었을 때 EOF 에러메세지를 나타낸다.

3. 네트워크가 중간에 끊어 졌을 경우

     jar 파일이 실행 되고 있는 서버에 대해 Inbound 및 Outbound 패킷이 흐르지 못하게 변경해놓고 실행하여 봤다.

    해당 Processing of multipart/form-data request failed. null] with root cause 에러가 발생 한다.

java maven build 시 cannot find symbol Error가 발생 하였다.

나의 환경은 spring boot module project로 구성 되어 있으며

parent 프로젝트를 maven build 시 각 각의 module 프로젝트들이 build가 된다.

나의 해당 컴파일 Error parent 프로젝트의 pom에 모듈 선언 부분에서 공통으로 사용하는 프로젝트에 관련하여 모듈이 삭제 되어 있었음.

해당 오류는 문자열의 오탈자나 bulid path, pom.xml의 dependency 확인이 필요 한 에러 같다.

https://github.com/cloudfoundry/bosh/issues/1689 <<< cloud foundrty git Issues

위 링크 git hub 이슈를 참조하여 보면

Director VM의 CPU 또는 Memory가 부족하여 발생 한 에러 일 가능성이 있다.

Director의 CPU와 Memmory를 재설정 하여 Deploy 해보니 배포가 성공 하였다.

또는 CF와 Diego에 할당 된 CPU를 줄여 주면 배포가 성공 할 수도 있을 것 같다.

아래는 배포 된 VM의 목록

application.properties에 아래 문구를 추가 한다.

server.jsp-servlet.init-parameters.development=true

Key Pair를 사용하여 VM(가상 머신) 접속 시 Too many authentication failures for vcap 에러 해결 방법

ssh -o IdentitiesOnly=yes -i ~/.ssh/private_key_or_pem_file_name server_user_name@ip_OR_hostname echo ok

를 활용 하면 성공적으로 들어 가진다...

Azure ruby 테스트를 shell을 이용해 전체 돌리 던 중

단위 테스트가 아닌 통합 테스트에서 에러가 발생

발생한 에러 status 는 401 아예 권한이 없다는 에러

아래는 MOCK 데이터

MOCK_AZURE_SUBSCRIPTION_ID        = 'aa643f05-5b67-4d58-b433-54c2e9131a59'

MOCK_DEFAULT_STORAGE_ACCOUNT_NAME = '8853f441db154b438550a853'

MOCK_AZURE_STORAGE_ACCESS_KEY     = '3e795106-5887-4342-8c73-338facbb09fa'

MOCK_RESOURCE_GROUP_NAME          = '352ec9c1-6dd5-4a24-b11e-21bbe3d712ca'

MOCK_AZURE_TENANT_ID              = 'e441d583-68c5-46b3-bf43-ab49c5f07fed'

MOCK_AZURE_CLIENT_ID              = '62bd3eaa-e231-4e13-8baf-0e2cc8a898a1'

MOCK_AZURE_CLIENT_SECRET          = '0e67d8fc-150e-4cc0-bbf3-087e6c4b9e2a'

MOCK_SSH_PUBLIC_KEY               = 'bar'

MOCK_DEFAULT_SECURITY_GROUP       = 'fake-default-nsg-name'

아래는 통합 테스트  변수 선언 부분

describe Bosh::AzureCloud::Cloud do

  before(:all) do

    @subscription_id                 = ENV['BOSH_AZURE_SUBSCRIPTION_ID']                 || raise("Missing BOSH_AZURE_SUBSCRIPTION_ID")

    @tenant_id                       = ENV['BOSH_AZURE_TENANT_ID']                       || raise("Missing BOSH_AZURE_TENANT_ID")

    @client_id                       = ENV['BOSH_AZURE_CLIENT_ID']                       || raise("Missing BOSH_AZURE_CLIENT_ID")

    @client_secret                   = ENV['BOSH_AZURE_CLIENT_SECRET']                   || raise("Missing BOSH_AZURE_CLIENT_secret")

    @stemcell_id                     = ENV['BOSH_AZURE_STEMCELL_ID']                     || raise("Missing BOSH_AZURE_STEMCELL_ID")

    @ssh_public_key                  = ENV['BOSH_AZURE_SSH_PUBLIC_KEY']                  || raise("Missing BOSH_AZURE_SSH_PUBLIC_KEY")

    @default_security_group          = ENV['BOSH_AZURE_DEFAULT_SECURITY_GROUP']          || raise("Missing BOSH_AZURE_DEFAULT_SECURITY_GROUP")

    @resource_group_name_for_vms     = ENV['BOSH_AZURE_RESOURCE_GROUP_NAME_FOR_VMS']     || raise("Missing BOSH_AZURE_RESOURCE_GROUP_NAME_FOR_VMS")

  end

MOCK 데이터와 통합 테스트 변수 선언 부분의 불일치로 인한 에러

통합 테스트는 실제 변수 값을 넣어 줘야 한다.

테스트의 변수 타입이 시스템 환경 변수를 저장하고 있는 해쉬 객체 타입으로

변수 값 설정 

export BOSH_AZURE_DEFAULT_SECURITY_GROUP=nsg-cf

export BOSH_AZURE_RESOURCE_GROUP_NAME_FOR_VMS=innovation

export BOSH_AZURE_RESOURCE_GROUP_NAME_FOR_NETWORK=innovation

export BOSH_AZURE_PRIMARY_PUBLIC_IP=52.231.37.142

export BOSH_AZURE_STORAGE_ACCOUNT_NAME=boshinnov2

export BOSH_AZURE_VNET_NAME=cf1innov

export BOSH_AZURE_SUBNET_NAME=cf1

export BOSH_AZURE_INSTANCE_TYPE=Standard_A2

...

설정 후 다시 Shell을 실행 하니 성공적으로 완료 되었다.

IaaS는 오픈스택이며 PaaS 위에 올린 젠킨스 서버에서 젠킨스 배포 중 테스트에는 이상이 없거나 설정 파일을 설정 하고 OK를 클릭 했을 때  No space left on device 에러가 발생 한 경우 해결 방법 (root 용량 부족)

젠킨스 배포시 Bulid history에 

Maven 로컬 기본 저장소 .m2 폴더와 jenkins 실행 로그가 남게 되는데 젠킨스 배포가 200번을 넘기면서 로그가 축적 되서 쌓이는데 계속 쌓이다 발생 한 에러의 경우 였다.

1. 젠킨스 서버 접속 ssh -i <key> vcap@<젠킨스 서버 Public IP>

2. $ df -h 명령어를 실행 하여 젠킨스 서버의 남은 용량을 확인 한다.

3. 젠킨스 재설치를 준비 한다.

4. 백업 할 데이터를 PaaS의 영구 데이터 디렉토리 /dev/vdb1 이동 시킨다.

4. PaaS 위에 올릴 젠킨스 서버의 용량을 기존의 20G -> 60G로 할당

5. 젠킨스 서버 배포 파일을 실행 하여 재설치

6. 재설치 완료 후 root에 있는 .m2 파일을 ln -s {source-filename} {symbolic-filename} 을 이용하여 가상화 된 디렉토리에 링크를 걸어 준다.

7. 젠킨스 재 실행