Develop Destroyer

1.1         컨테이너 기술의 개요

컨테이너란?

컨테이너란 호스트 OS 상에 논리적인 구획(컨테이너)을 만들고, 애플리케이션을 실행시키는데 필요한 라이브러리나 애플리케이션 등을 하나로 모아 그것을 마치 전용 서버인 것처럼 사용할 수 있게 만든 것

컨테이너 기술에는 여러 가지가 있지만, 현재 쿠버네티스의 기본값으로 되어 있는 것은 도커(Docker)다.

호스트형 서버 가상화

호스트형 서버 가상화는 하드웨어상에 베이스가 되는 호스트 OS를 설치하고 호스트 OS에 가상화 소프트웨어를 설치한다.

컨테이너와는 달리 호스트 OS상에서 다른 게스트 OS를 작동시키므로 오버헤드가 매우 커진다.

하이퍼바이저형 서버 가상화

컨테이너 기술은 애플리케이션의 실행 환경을 모아놓음으로써 이식성을 높이고 스케일러블한 환경에서도 작동하는 것을 지향하고 있다.

컨테이너 애플리케이션 개발자의 흐름

(1)  컨테이너 애플리케이션의 빌드

도커는 애플리케이션의 실행에 필요한 프로그램 본체, 라이브러리, 미들웨어나 OS, 네트워크 설정 등을 하나로 모아 도커 이미지를 만든다. 도커의 경우 하나의 이미지에는 하나의 애플리케이션에만 넣어두고

여러 컨테이너를 조합하여 서비스를 구축할 것을 권장한다.

(2)  컨테이너 이미지 공유

컨테이너 이미지는 레시스트리로 공유할 수 있다. 예를들어 도커의 공식 레지스트리인 Docker Hub에서는 Ubuntu나 CentOS와 같은 리눅스 디스트리뷰션의 기본 기능을 제공하는 베이스 이미지가 배포되어 있다.

(3)  컨테이너 애플리케이션의 실행

도커는 리눅스 상에서 컨테이너 단위로 서버 기능을 작동시킨다.

또 도커 이미지로부터 여러 개의 컨테이너를 시작시킬 수도 있다.

1.2         쿠버네티스의 개요

분산 환경에서 컨테이너 운용 관리

컨테이너는 개발 환경처럼 한 대의 머신에서 가동시킬 때는 손 쉽게 도입할 수 있다.

하지만 멀티호스트로 구성된 클러스터 구성에서 가동시키려면 컨테이너의 시작 및 정지와 같은 조작뿐만 아니라 호스트 간의 네트워크 연결이나 스토리지 관리, 컨테이너를 어떤 호스트에서 가동시킬지와 같은 스케줄링 기능이 필요하다.

게다가 컨테이너가 정상적으로 작동하고 있는지 아닌지를 확인하는 장치도 필요하다.

이러한 기능을 갖추고 있으면서 컨테이너를 통합 관리할 수 있는 툴을 컨테이너 오케스트레이션 툴이라고 한다.

쿠버네티스, 도커(Swarm 모드), Apache Mesos/Marathon

쿠버네티스의 특징

쿠버네티스는 대규모 분산환경에서 소수의 에지니어 만으로 컨테이너 애플리케이션을 관리하는 것을 모걱으로 한 오케스트레이션 툴이다.

쿠버네티스는 하드웨어 인스라스트럭쳐를 추상화하여 데이터센터 전체를 하나의 방대한 계산 리소스로 간주한다. 그 결과 개발자는 실제 서버를 의식할 필요 없이 컨테이너 애플리케이션을 디플로이하여 실행할 수 있다.

쿠버네티스의 주요 기능

-      여러 서버에서 컨테이너 관리

-      컨테이너 배포

-      컨테이너간 네트워크 관리

-      컨테이너 부하분산

-      컨테이너 감시

-      컨테이너 업데이트

-      장애 발생 시 자동 복구

이러한 내용들은 선언적 설정과 API 센트릭이 있다.

쿠버네티스에서는 ‘시스템이 원래 되어 있어야할 모습’을 정의 파일에 설정하여(선언적 설정) 장애가 발생해도 사람이 개입하지 않고 원래 되어 있어야 할 모습으로 수습할 수 있다.

일단 쿠버네티스를 시험해 보고 싶은 경우는 퍼블릭 클라우드가 제공하는 매니지드 서비스를 이용할 것을 권장한다.

Amazon Elastic Container Service for Kubernetes(Amazon EKS)

Google Kubernetes Engine(GKE)

Azure Kubernetes Service(AKS)

쿠버네티스의 유스케이스

마이크로 서비스의 운용 관리

쿠버네티스가 갖고 있는 수평 스케일링, 자기 복구, 부하 분산 등과 같은 기능을 활용 할 수 있다. 영구 데이터ㅢ 관리는 컨테이너가 아니라 클라우드의 데이터 관리 서비스를 사용하는 것이 좋다.

기계학습의 워크로드

대규모 데이터셋을 사용하는 심층학습의 트레이닝은 파라미터나 서버나 분산 학습을 위한 워커노드를 관리해야 한다. 컴퓨팅 리소스를 많이 필요로하는 워커노드에는 CPU와 같이 고가의 하드웨어를 온디맨드로 할당하도록 제어할 수 있다.

이 취약점으로 주말에 잘쉬고 있다가 갑자기 일을 하게 되었다.. 보편적으로 안쓰는 업체가 찾기 힘든 라이브러리에서 크리티컬한 취약점이 발견된 것이다. 이후에도 지속적으로 개발 커뮤니티에도 해당 이슈가 올라와서 나도 내가 아는바에 대한 내용을 기록으로 남겨본다

[개요]

자바 기반으로 만들어지고 전세계적으로, 대중적(?)으로 많이 사용되는 로깅을 위한 라이브러리로 log4j가 있다.

이번 이슈가 된 취약점은 log4j가 넘겨받은 변수를 그대로 로깅하는 것이 아니라 해당 변수를 분석해 실행할 수 있는 lookups 기능에서 발견되었다. lookups란 예를들어 log.error("에러 : " + result); 에서 result가 ${env:PASSWORD}로 설정되어 있다면 "에러 : ${env:PASSWORD}"를 그대로 로깅하는 것이 아니라 이에 해당하는 설정값을 찾아 "에러 : qwer1!"를 로깅하게 되는 기능이다. lookup에는 여러가지 기능들이 있는데, 이번 케이스는 JDNI 룩업을 이용한 공격이 가능하다는 취약점이다. 이른바 Log4Shell 취약으로 불린다.

[취약점 공격 대상]

log4j-core 버전 2.10.0 이상 ~ 2.15.0 미만

[대응방법]

1. log4j를 2.15.0 이상으로 업그레이드 한다. (Java8 이상에서만 기동된다)

2. log4j 2.10.0 이상 사용 시 다음의 방법 중 한 가지 이상의 방법을 사용한다. 개인적인 의견으로는 서비스의 운영환경마다 다르겠지만.. 운영하는 웹서비스가 많아 관리 포인트가 많고 복잡할 경우.. 이 방법은 관리측면에서는 별로 좋은 방법 같진 않다. 개발자가 프로젝트 소스코드 외부에서 관리해야하고(서버/인프라 단), 이 설정이 되어있는 이유에 대해 나중에 시간이 많이 지나서 누가 보더라도 알 수 있도록 히스토리를 잘 관리해야 한다는 점..

•  
• Java 실행 인자(Arguments) 에 시스템 속성을 추가한다. -Dlog4j2.formatMsgNoLookups=true
• Java 실행 계정의 환경 변수 혹은 시스템 변수로 LOG4J_FORMAT_MSG_NO_LOOKUPS=true를 설정한다.

3. log4j 2.7.0 이상 사용 시 log4j 설정(log4j.xml 등)에 PatternLayout 속성에 있는 %m 부분을 %m{nolookups} 으로 교체한다.

4. 만약 log4j 버전이 2.10.0보다 낮다면, 이번 이슈의 공격대상은 아니다.. 그렇지만 1버전 대의 경우는 지원이 중단되었으며, 이미 RCE 보안이슈가 존재하므로 가급적 업그레이드 방안을 모색하는 것이 좋다

[팁]

위 대응방법은 기본적인 조치 방법에 대해 설명한 것이고, 이와 더불어 조치 시 아래 오픈소스를 참고하면 빠르게 조치할 수 있다.

https://github.com/logpresso/CVE-2021-44228-Scanner

해당 소프트웨어를 서버로 옮겨서 웹서비스가 설치된 디렉토리를 중심으로 탐색하면 대상 log4j를 사용중인지 확인 할 수 있다. 사용방법은 해당 레포지토리 README에 상세히 나와있고 매우 간편하다.

그리고 우리 서비스 외에도 밴더 솔루션등에도 log4j 이슈가 있을 수 있으니 꼭 문의를 넣어서 확인해보자

이 가이드는 솔라나 지갑을 이미 보유한 상태에서 진행함

1. solona CLI를 설치한다. 아직까지는 연구단계임에따라 윈도우 환경 전용으로 설치하였는데 생각보다 잘 동작한다

2. 다음 명령어에 따라 내 지갑에 연결된 토큰 account 정보를 확인해볼수 있다.

C:\WINDOWS\system32>spl-token accounts
Token                                         Balance
---------------------------------------------------------------
83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ  90
85iewBw7g5xzTBPsmEhRT6UyVHjZKkH2QzxR6Hpxp4AM  10  (Aux-1*)
HuJCd48ycmqS5ADDnprxzbPoTAH2FQwYY92SdFC4tZgs  10  (Aux-1*)

참고로 위 과정 중 특정위치에 있는 계정정보파일을 읽을 수 없다면 에러가 뜰것이다. solona config 명령어를 통해 계정정보가 어디에 저장돼는지 확인 할 수 있으며 계정정보가 없다면 자신의 지갑 개인키를 배열(엄밀히 따지자면 json)의 형태로 저장해주면 된다. (ex. [13, 103, 34, 534 ...] 이런 형태로 저장된다. 이 값은 sollet.io에서 접속한 뒤 자신의 지갑에서 export를 하면 해당 파일을 얻을 수 있다.. 직접 이렇게 변환하는 방법도 알고싶은데 어디에서인지 아직 알 수 없음;

3. 토큰을 새로 생성한다.

intput

spl-token create-token

output

Creating token 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ

Signature: 4ELSGXv7Eh6sFnzcM7XvVLmZUZrWbCsF7DoKYpj14qmMzohh9b79AqTXnUYTaLKUuFQLASBHrPMKhEbrM7h8cjMr

4. 이제 생성한 토큰을 집어넣을 token account를 만들어준다. 왜이렇게하는건지는 아직 이해하지 못하겠으나... 본 지갑에서 서브형태로(?) 종속된 account를 만들어서 거기에 방금 3에서 생성한 토큰을 넣어줄것이다.

intput

spl-token create-account 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ

output

Creating account 3mMDq1JaT3jRWyJkK7tZuy9E9jJFCey83Kj2WK6Lk1Ei

Signature: 42Sa5eK9dMEQyvD9GMHuKxXf55WLZ7tfjabUKDhNoZRAxj9MsnN7omriWMEHXLea3aYpjZ862qocRLVikvkHkyfy

5. 새로만든 account를 확인해보자

solana balance 3mMDq1JaT3jRWyJkK7tZuy9E9jJFCey83Kj2WK6Lk1Ei

6. 토큰을 다음과 같은 형태로 민트한다

spl-token mint tokenAddress mintAmount recipientAddress

예시는 아래와 같다

spl-token mint 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ(토큰) 100(발행량) 3mMDq1JaT3jRWyJkK7tZuy9E9jJFCey83Kj2WK6Lk1Ei(토큰account)

7. 이제 다음과 같이 발행된 토큰을 확인해 볼 수 있다.

spl-token accounts

Token Balance

------------------------------------------------------------

83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ 1000000

8. 발행한 토큰을 다른 지갑으로 전송해본다

spl-token transfer --fund-recipient tokenAddress transferAmount recipientAddres

아래는 예시

input

spl-token transfer 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ 30 vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg

output

Transfer 50 tokens Sender: 7UX2i7SucgLMQcfZ75s3VXmZZY4YRUyJN9X1RgfMoDUi Recipient: vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg Recipient associated token account: F59618aQB8r6asXeMcB9jWuY6NEx1VduT9yFo1GTi1ks Signature: 5a3qbvoJQnTAxGPHCugibZTbSu7xuTgkxvF4EJupRjRXGgZZrnWFmKzfEzcqKF2ogCaF4QKVbAtuFx7xGwrDUcGd

실수로 merge를 하였을 경우 다음과 같이.. reset을 해버리자

git reset --merge ORIG_HEAD

위 명령어를 사용하면 원격지와의 head와 로컬의 head가 상이하여 push시도시 에러가 발생한다.

git push -f origin master

-f (force)를 사용하여 강제로 push해야한다.

https://jongmin92.github.io/2018/02/04/Spring/springboot-start/

        axios.get('/api/test')
          .then(function(response){
            this.list = [];
           }); 

이렇게 짜면 vue의 데이터 객체 list의 내용을 비우라는 것으로 착각하기 쉽지만...

이렇게 했을때 this는 vue의 this가 아니다... 이 상황에서의 this는 axios를 가리키는 것이다.

따라서 클로저 형태로 접근해야 하는 번거로움이 생긴다..

제일 간단한 방법은

        var vm = this;

        axios.get('/api/test') 
          .then(function(response){ 
            vm.list = []; 
           });  

이렇게 axios 바깥에서 this를 별도 변수에 넣어서 넘겨쓰는것.

php 설정상의 문제인줄 알고 한참을 헤맸으나

seLinux상의 문제임을 확인하였다.

아래 명령어를 통해 네트워크 엑세스를 허용해주면 된다

setsebool -P httpd_can_network_connect 1

요즘 만들고 있는 사이드 프로젝트에서 필요한 API를 찾다가 MAP API를 간략하게나마 정리하게 되었습니다. 너프하게 찾은 자료지만 쉽게 보시기엔 편할거에요 :)

NAVER : MAP API (1day, 200000 call)

• 네이버 MAP은 하루 20만콜이 무료이다. 갯수도 비교적 적지만 그렇다고해서 가이드가 뛰어나 보이진 않는다.(필자 주관임)
• https://navermaps.github.io/maps.js/docs/index.html

KAKAO : MAP API (1day, 300000 call, dev guide is perfect)

• KAKAO MAP API는 상당히 여러가지 기능과 인터페이스를 제공한다. 심지어 30만콜이 무료이며 가이드가 상당히 잘 짜여져있다.
• http://apis.map.kakao.com/web/guide/

Google : MAP API (payment required.. : 200,000won credit free when creating an account.)

• 결제계정 생성 시 대충 20여만원의 크레딧을 제공한다. 이후로는 유료인가보다...
• https://cloud.google.com/maps-platform/?hl=ko

NAVER : local API (1day, 25000 call)

• 이건 맵 API가 아니라 Local 검색 API이다. 서비스를 만들 때 특정 매장 등과 같은 정보를 검색 할 수 있는 기능을 만들어야 하는데 이러한 상황에서 쓰면 유용하다 1일 25000콜 무료이다.
• https://developers.naver.com/docs/search/local/

결론 : 저는 검색의 경우 NAVER API(한국 서비스를 만들거라면 아무래도 네이버가 제일 나은 플랫폼이라고 생각해요), 여기서 검색한 결과를 지도에 뿌려주는 것은 KAKAO API를 이용하려고 합니다.

AWS Free-tier는 이전에도 사용경험이 있고 상세한 설치 설명도 구글검색을 통해서 확인해 볼 수 있지만
이번 기회를 통해서 언제든 신속하게 환경구성을 할 수 있도록 저만의 가이드를 작성해보고자 합니다.

우선 가상서버 EC2를 구성해야하는데요, 어떤 OS를 선택할지에 대해서도 고민이 필요했습니다.
일반적으로 AMI와 Redhat, Unbuntu.. 등등 여러가지 시스템환경을 지원하는데요
이번 프로젝트의 경우 Redhat을 이용하여 환경을 구축하였습니다.
AMI는 AWS에서 지원하는 리눅스지만, 안정성 면에 있어서는 타 리눅스 계열과 비교적 취약하다는 의견들이 많이 보입니다.
Ubuntu는 제가 학생이었을 때 여러차례 다루어본 바 있고 이미 너무 유명한 제품이지만 상용에서 쓰는 것을 그리 많이 보진 못하였습니다.
엔터프라이즈급 서비스에서 많이 쓰는 리눅스 계열은 Redhat 데비안 쪽을 많이 이용한다고 하네요.
자세한 내용은 아래 링크를 확인해주세요.
https://serverfault.com/questions/275736/amazon-linux-vs-ubuntu-for-amazon-ec2
https://okky.kr/article/395579?note=1245081

Free-tier의 서버 스펙을 간략히 설명하자면 다음과 같습니다.
 - EC2 : 월 750시간의 Linux, RHEL 사용
 - CPU 1 core
 - Memory 1GiB
 - EBS : 30GB

EC2를 Free-tier에서 선택가능한 옵션으로 생성해줍니다.
EC2는 참고로 재부팅할때마다 공인IP가 변경되기 때문에
Elastic IP로 변경해주어야 합니다. Free-tier는 1개 EC2에 연결하는 것이 무료 입니다.
참고적으로 연결해둔 상태로 EC2를 끄고있으면 과금이 된다고하네요.(공인 IP는 한정적인 자원이므로 이러한 정책이 있다고 하니 주의가 필요합니다)
Elastic IP를 생성하고 아까 생성한 EC2에 릴리즈해주면, Elastic IP로 EC2 네트워크에 접속할 수 있습니다.

앞서 요약한것과 같이 Free-tier에서는 EBS가 30GB입니다. EBS는 가상 스토리지로써
하드디스크와 같은 역할을 합니다.
EC2의 SSD는 웹서버로 이용하고, EBS를 유저들의 데이터를 입출력하는 장치로 활용하면 좋을 것 같습니다.
그런데 기본적으로 맨처음 EC2를 만들면서 자동생성된 EBS는 10GB밖에 안됩니다.. 첨부터 30GB로 해주지 ㅡㅡ;;
저는 이걸 AWS콘솔에서 30GB로 변경해주었습니다.
하지만 실서버에서는 이미 파티션을 10GB로 잡고 있기때문에 직접 변경해주는 작업이 필요했습니다.
상세한 내용은 다음을 참고해주세요.
https://sfixer.tistory.com/entry/%EB%94%94%EC%8A%A4%ED%81%AC-%EB%B3%BC%EB%A5%A8-%EC%82%AC%EC%9D%B4%EC%A6%88-%EC%A6%9D%EA%B0%80%EC%8B%9C%ED%82%A4%EA%B8%B0
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

이렇게 기본적인 서버 인프라는 갖추었으니 LAMP 환경을 구축하고 마무리 지었습니다.
LAMP에 대한 설치 프로세스는 위키메뉴의 Reference에서 관련된 문서들을 확인 할 수 있습니다.

1. 우선 생성일시를 임의로 조작한 파일을 생성한다. 두개를 생성해야 한다. 조회하고자하는 기간의 시작일시와 끝일시로...

# touch -t 201906031200 start.txt 

# touch -t 201906031500 end.txt 

위의 경우 19년 6월 3일 12시부터 15시까지의 추가, 수정된 파일을 찾기 위해 임시 파일을 생성한 것이다. -t 옵션을 주고 입력한 시간대로 생성일시가 조작되어 생성된다.

2. 검색하기

# find /tmp -type f -newer start.txt ! -newer end.txt -ls

아까 생성했던 임의의 파일 두개를 저렇게 옵션으로 넣어준다. -newer는 입력된 파일을 기준으로 이후에 생성된 것들을 찾아주는 것인데, !(부정)을 활용하여 이전에 생성했던 것까지 추가해주면 특정 기간동안의 파일을 검색 할 수 있게 된다.