간단한 리마인드

 

일반적인 개념보다 앞으로의 방향이 어떻게 되어갈 것인지에 대하여 궁금하여 조금 더 공부를 해보고자 한다. 

 

컨테이너의 미래는 어떻게 될까? 출처 maritime NZ

 

컨테이너는 어플리케이션, 라이브러리, 설정 등을 하나의 단일한 패키지로 묶어 격리된 환경에서 실행하는 방식을 채택하고 있다. 기본적으로 컨테이너는 가상화 기술의 일종으로, 가상머신과 비슷한 목적을 가지고 있지만 그 실행 방식과 효율성 면에서 큰 차이를 보인다.

 

효율성면에서 큰 차이를 보인다-? 

이전에 VM 을 앱 배포에 채택하였던 구글 조상들의 고충은 뭐였을까.

 

가상머신은 운영체제와 함께 동작하는 풀 스택의 가상 환경을 제공하는데, 이로 인해 무겁고 느리게 동작하는 단점이 있었다. 반면에 컨테이너는 호스트 운영체제의 리소스를 효율적으로 활용하면서도 격리된 환경을 제공하여 가볍게 동작할 수 있도록 고안되었다. 아래 정리된 컨테이너의 장점을 보면 더 이해가 갈 것이다.

 

  • 격리(Isolation): 컨테이너는 각각이 독립된 환경에서 동작하기 때문에 한 컨테이너의 변화가 다른 컨테이너에 영향을 미치지 않습니다. 이는 애플리케이션 간 충돌을 방지하고 보다 안정적인 운영을 가능하게 한다.
    예시: 서로 다른 버전의 어플리케이션을 동시에 실행하거나 특정 환경에서의 실험을 위해 격리된 컨테이너를 사용할 수 있다.
  • 가상화(Virtualization): 컨테이너는 가상머신과 유사한 가상화 환경을 제공하지만, 가볍고 빠르게 실행됩니다. 이는 높은 성능과 빠른 배포를 가능케 하며, 여러 컨테이너를 동시에 실행할 수 있다.
    예시: 빠른 확장이 필요한 경우, 컨테이너를 사용하여 더 빠르게 새로운 인스턴스를 추가하고 활용할 수 있다.
  • 이식성(Portability):
  • 컨테이너는 실행 환경과 상관없이 동일하게 작동하므로, 개발 환경에서 테스트한 애플리케이션을 프로덕션 환경에 그대로 배포할 수 있다.
    예시: 로컬 환경에서 애플리케이션을 개발하고, 동일한 컨테이너 이미지를 사용하여 클라우드나 다른 서버에 배포할 수 있다.
  • 자동화(Automation):
  • Docker와 같은 컨테이너 도구는 애플리케이션 빌드, 배포, 확장 등을 자동화하여 개발 및 운영 효율을 높인다.
    예시: 코드 수정 시 자동으로 빌드되고, 업데이트된 애플리케이션이 자동으로 배포되는 등의 작업이 자동으로 이루어진다.
  • 관리 및 오케스트레이션(Management and Orchestration):
  • 컨테이너 오케스트레이션 도구들은 여러 컨테이너를 효과적으로 관리하고 확장하는 데 사용된다.
    예시: Kubernetes는 컨테이너를 클러스터로 구성하여 효과적으로 관리하고, 필요에 따라 자동으로 확장하거나 축소할 수 있다.

 

이제 궁금했던 점으로.

 

컨테이너의 향후 방향은 어떻게 진행 되어가고 있을까?

 

 

AI 및 자동화의 통합 : 사실 이 문제는 컨테이너 뿐 아니라 클라우드 관리 전반에 걸쳐 영향을 미치지 싶다. 솔직히 말하면 개발이고 운영이고 인프라고 생태계 전체를 송두리째 바꿔놓을 것 같다.

 

나는 node 베이스의 개발자로 AI 에 대해 잘은 모른다.

 

web2vec을 활용한 python 엔진을 몇 차례 돌려 보았던 정도. 그래도 open-ai 에서 베타로 출시한 assistant 와 다양한 feature 들, 그리고 open-ai 의 최신 엔진은 나올때마다 계속해서 물고 뜯고 적용해보고 있다.

 

( 무지막지한 회사 프로젝트의 연속 덕분이다 )

 

그래봤자 까막눈 수준, 이러한 내가 보았을때도 open-ai 는 확실히 말도 안되는 데이터의 양과 AI 성능을 보여준다. hugging face 를 비롯하여 open source 로 git에 올라오는 엔진들의 수준에 비하면 그냥 경이로울 정도의 격차라고 생각한다. 일반인들이 생각하는 AI 현실화는 더 가속화되지 않을까 싶다. 실제로 open-ai 엄청나게 써대고 있으니까 더 빨라지지 않을까.

 

우리는 이제 끝났다.

 

다중 클라우드 및 하이브리드 클라우드 지원 : 기업들은 고객 요구 사항 및 비용 효율성 등을 고려하여 여러 클라우드 환경을 동시에 활용하거나, 하이브리드 클라우드 환경을 적용하려는 경향이 있다. 컨테이너는 환경 간 이식성이 뛰어나기 때문에 다중 클라우드 및 하이브리드 클라우드에서의 활용이 강조되어가고 있는 추세이다.

 

이미지 업로드 = 리소스 절감 이 공식처럼 되어버렸다.

아마 IT 기술에 대해 잘 모르는 대표들도 컨테이너로 배포하라는 말은 어디서 듣고와서 입에 달고 살지 않을까 싶다.

 

Container 와 전혀 무관한 사진이다.

 

서버리스 컨테이너 활용의 확대 : 서버리스 컨테이너 기술은 더욱 진화하여, 애플리케이션의 작은 부분들을 빠르게 실행하고 관리하는 데에 더 큰 중요성을 갖게 될 것으로 예상된다고 한다. 마이크로 서비스 단위로 계속해서 쪼개지는 것이다. 사실 현재에도 잘 설계된 서비스들은 사용하는 양에 따라 리소스가 조정되고 매니징되고 컨테이너 별로 잘 나뉘어져 있다. 더 쪼갤 필요성이 없다는 것이다.

 

service 의 단위를 마냥 쪼개는 것이 효율적이지는 않을 것이다. 리소스는 절감되지만 사람은 살려달라고 소리를 지르게 되지 않을까. 그걸 모니터링 하는 건 결국 휴먼이니까. - 다만, AI가 적용된다면 이것 또한 새로운 이야기일 것이다. 그때는 Container 개념이 아니라 AWS의 Lambda 와 더 가까워지겠지..

 

 

 

 

컨테이너에 대한 리마인드,

끄적끄적 생각 끝. 

 

에이전트 풀이란 뭘까? 

 

에이전트 풀은 마이크로소프트의 Azure DevOps에서 사용되는 공간이다.

이해하기 쉽게 설명하면, 이 공간에는 작업을 수행하는 작은 개체들이 있고 이 작은 개체들을 '에이전트'라고 부른다.

 

에이전트 풀은 누군가 자체적으로 만들어야 하는 것이 아니라 마이크로소프트에서 미리 만들어 놓은 공간이다. 이곳에는 다양한 종류의 작업을 할 수 있는 여러 기능이 준비되어 있다. 

 

그런데 가끔은 마이크로소프트에서 만들어 놓은 에이전트가 아니라, 우리가 직접 만든 커스텀 에이전트를 사용하고 싶을 때가 있을 것이다. 이때 에이전트 풀을 만들고, 그 안에 커스터마이징 한 에이전트를 넣어둘 수 있다. 이렇게 만든 풀을 '자체 호스팅 에이전트 풀'이라고 부르고, 그 안에 들어가 있는 개체를 '자체 호스팅 에이전트'라고 부른다.

 

 

에이전트 풀이 왜 필요할까?

 

당신이 레고 블록으로 무언가를 만든다고 상상해봐라. 에이전트 풀은 그 레고 블록을 담아두는 상자이다. 상자 안에는 여러 종류의 블록이 있어서 필요할 때마다 쉽게 가져와서 사용할 수 있다. 때로는 커스터마이징 된 블록도 상자에 담아두고 싶을 때가 있을 것이다. 에이전트 풀을 사용하면 그런 작업을 할 수 있게 한다.

 

말을 반복해서 다시 한번 요약해보면, 에이전트 풀은 작업을 처리하는 개체들을 담아두는 특별한 공간이다. 에이전트 풀을 사용하면 작업을 효율적으로 처리할 있고, 필요할 때마다 필요한 개체만을 사용할 있다.

 

에이전트 풀에는 2 type 이 있는데 무료로 사용할 수 있는 Microsoft 호스팅 풀이 있으며(일부 제한이 존재하기는 함), 또는 자체 호스팅된 에이전트를 만들어 자체 호스팅 풀에 연결할 수 있다.

 

  • Azure Pipelines: 기본 Microsoft 호스팅 풀로서 다양한 Ubuntu, MacOS 및 Windows Server 에이전트를 사용한다.
  • Default: 자체 호스팅된 에이전트를 연결 방식을 의미한다.

 

그래서 에이전트가 뭘 하는데?

 

1. 작업 실행 

에이전트의 주된 역할은 빌드 또는 릴리스 파이프라인에서 정의된 작업을 실행하는 것이다. 코드를 컴파일하거나 테스트를 실행하고 응용 프로그램을 배포하는 등의 개별 단계나 동작을 의미한다.

 

2. 환경 설정

에이전트는 작업에 필요한 런타임 환경을 설정한다. 이는 종속성을 설치하고 설정을 구성하며 파이프라인에서 정의된 특정 작업을 실행하기 위한 환경을 준비하는 것을 의미한다.


3. 아티팩트 검색 및 게시

에이전트는 빌드 프로세스에서 필요한 소스 코드 및 기타 종속성을 검색한다. 성공적인 빌드 후, 에이전트는 아티팩트(컴파일된 이진 파일, 패키지)를 Azure DevOps에 게시하여 이후의 작업이나 단계에서 사용할 수 있도록 한다.


4. 테스트 실행

빌드 파이프라인의 맥락에서, 에이전트는 주로 코드의 품질을 보장하기 위해 테스트를 실행한다. 이는 단위 테스트, 통합 테스트 또는 프로젝트에서 정의된 기타 테스트를 포함하는 의미이다.


5. 배포

릴리스 파이프라인에서 에이전트는 응용 프로그램이나 서비스를 다양한 환경(스테이징, 프로덕션 등)에 배포하는 데 중요한 역할을 한다. 에이전트는 배포 작업을 실행하고 구성을 관리하며 응용 프로그램이 올바르게 배포되도록 보장한다.


6. Azure DevOps 서비스와의 통신

에이전트는 지시를 얻고 진행 상황을 보고하며 업데이트를 받기 위해 Azure DevOps 서비스와 통신한다. 에이전트는 안전하고 신뢰성 있는 상호 작용을 위해 안전한 연결을 사용하며 개인 액세스 토큰(PAT)을 사용하여 인증한다.


7. 병렬 실행

에이전트는 병렬 실행을 지원하여 여러 작업이 동시에 실행될 수 있도록 한다. 이는 대규모 프로젝트에서 특히 효율성을 높이는 데 도움이 된다.

 

8. 로그 및 보고

에이전트는 작업 및 작업 실행 중에 로그를 생성한다. 이 로그는 각 단계에 대한 자세한 정보를 제공하며 문제 해결이나 파이프라인의 진행 상황을 이해하는 데 도움이 된다. 


요약하면, 에이전트는 Azure DevOps 파이프라인에서 정의된 지시를 따라 수행하는 다재다능한 작업자로 볼 수 있다. 환경 설정, 작업 실행, 테스트 실행, 응용 프로그램 배포 및 Azure DevOps 서비스와의 통신 등을 담당하여 원활하고 자동화된 DevOps 프로세스를 수행해준다.

1. IP

Internet Protocol 의 약자로 우리가 사용하고 있는 인터넷의 개인 주소라고 생각하면 된다.

IP에는 IPv4와 IPv6 두 가지 유형이 있는데, IPv4의 확장성과 용량면에서 한계를 해결하기 위해 IPv6가 등장하였다.

주소공간은 IPv4 - 32비트에서 IPv6 - 128 비트로 확장되었으며 인터넷 사용의 폭증을 수용하기 위해 IPv6로의 전환은 필수적이다.

 

my ip address 

온라인 검색 -> 통신사가 제공하고 있는 나의 ip주소 확인이 가능하다.

 

Terminal -> ipconfig

공유기에 의하여 할당받고 있는 ip주소. 통신사 -> 공유기에 의해서 여러 갈래로 그 주소가 분배되고 분배된 주소 중 내가 할당 받은 주소가 보여지는 IPv4주소이다. 

 

HTTP / HTTPS

둘다 프로토콜 (데이터 교환방식을 정의하는 체계) 을 의미하며 http와 같은 경우 인터넷 초기에 모든 웹사이트에서 기본적으로 사용되었던 프로토콜이다. 현재는 https가 권장되고, 또한 주로 사용되고 있는데 약자에서 알수 있듯이 (Hypertext Transfer Protocol Secure) https 프로토콜은 SSL을 사용함으로써 서버와 브라우저 사이에 암호화된 연결을 만들 수 있게 도와준다. 

 

SSL

SSL(Secure Sockets Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해 Netscape가 1995년 처음으로 개발되었으며 TLS 암호화의 전신이라고 할 수 있다.

 

이미지 참고 https://www.cloudflare.com/ko-kr/learning/ssl/what-is-ssl/

DNS (Domain Name System)

Amazon Route 53과 같은 DNS 서비스는 전 세계에 배포된 서비스로서, www.example.com과 같이 사람이 읽을 수 있는 이름을 192.0.2.1과 같은 숫자 IP 주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 한다. 인터넷의 DNS 시스템은 이름과 숫자 간의 매핑을 관리하여 마치 전화번호부와 같은 기능을 한다. 도메인은 서비스를 제공하는 CloudFlare나 cafe24 와 같은 기업에서 구매가 가능하다.

 

 

 

 

 


 

 

 

2. AWS EC2

 

Amazon Elastic Compute Cloud (Amazon EC2)는 500개가 넘는 인스턴스, 그리고 최신 프로세서, 스토리지, 네트워킹, 운영 체제 및 구매 모델의 옵션과 함께 워크로드의 요구 사항에 가장 잘 부합할 수 있도록 가장 포괄적이고 심층적인 컴퓨팅 플랫폼을 제공한다.

 

AWS EC2에서 인스턴스를 발급 받는 방법과 생성한 인스턴스에 tomcat을 설치하는 방법은 youtube나 google에 서칭해보면 매우 잘 나온다. 보면서 따라하기만 하면 된다. 인스턴스 생성과 tomcat을 설치한 이후,


(1) Tomcat Folder

인스턴스 내에 설치한 톰캣의 경로를 확인한다. 나의 경우 설치가 어디 되어있는지 opt와 var 폴더를 헤메다가 var>lib 폴더 내에 설치가 되어있는 것을 확인하였다. AWS terminal의 경우 해당 repo로 들어가기 위해서는 gitbash와 다르게 /(슬래시)를 명령어에 포함시켜주어야 한다. 윈도우가 아닌 리눅스 환경임을 기억하자.

 

cd /opt > ls

cd /var > ls

cd ./var /lib > ls > tomcat9 찾음

 

톰캣이 설치된 위치를 먼저 찾자


(2) Tomcat 설정 변경

var/lib/tomcat9/conf$ sudo nano tomcat-users.xml 

 

sudo nano tomcat-users.xml :

- sudo는 명령어를 실행할때 사용하는 리눅스 용어 

- nano는 linux 내의 에디터를 말한다. vim 에디터도 존재한다. 

- tomcat-users.xml은 말그대로 파일 이름.

 

tomcat9 폴더에서 cd conf 해주면 xml이 위치한 폴더로 들어갈 수 있다. 다음에 해당 sudo 명령어를 입력해서 xml을 열어주자. 나는 설정 몇 가지를 변경해주었다. 

 

tomcat 실행하는 김에 password와 username 변경해준다.

 

포트넘버도 8080에서 임의로 바꿔주었다.

 

나는 tomcat 설치하는 시점에 username과 password 설정을 건드리지 않았기 때문에 Id/Pwd 를 이때 변경해주었다. 

변경한 후에는 ctrl + o 눌러서 저장하는 것 잊지말자.


(3) Tomcat start

 

중요한 걸 빼먹을 뻔 했다.

톰캣 구동을 시켜줘야한다. ctrl + x 키로 저장한 xml을 닫아주고 ctrl + c 키로 명령어 창을 띄워준다. 

 

구동은 sudo systemctl start tomcat9 ( tomcat 버전 다르면 해당 버전으로...)

톰캣 끄는 명령어는 sudo systemctl stop tomcat9

 

중요한 것이 한 가지 더 있는데, tomcat9를 구동시키거나 꺼준 이후에는 sudo systemctl status tomcat9 로 구동 상태를 확인해주어야 한다.

 

왜냐하면

Linux는 ui가 매우 불친절하기 때문이다... 아니 ui가 없다...

 

 


(4) IP + Tomcat port #

 

 instance ip주소 + : instsance에서 tomcat 설정한 port 번호를 주소창에 입력하면 아래와 같이 tomcat이 성공적으로 구동되고 있음을 알려주는 화면이 나온다. (나의 경우 8080이 아닌 ex- 6452 port를 설정해주었기 때문에 151.621.6542 : 6452를 주소창에 입력해주었다.

 

발급받은 instance의 ip / + 하이픈 뒤에는 임의로 설정해준 port number


(5) war파일 배포.

 

it works 라는 문구를 확인하면 tomcat이 정상적으로 구동되고 있는 것이다. 해당 화면에서 manager webapp을 클릭하여 

하기 페이지로 넘어간다.

해당 이미지에서는 잘리긴 했는데, war File을 upload 할 수 있는 스페이스가 아래 더 있다.

 

STS 또는 Eclipse에서 파일을 export 해야한다. localhost:8080으로 프로젝트가 문제 없이 돌아가는 지 확인하고 나면

File -> export -> war 순서대로 프로젝트를 export 해주면 된다. 

 

이때 주의 할 점은, localhost에서 가장 처음으로 띄워졌던 화면의 주소가 localhost8080/Test01 라고 한다면 war file의 파일명도 Test01로 변경해주어야 한다는 점이다. 

 

이름 변경이 완료되었다면 file upload를 진행한 후 

 

 

 

 

 

 

 

 

 

 

++

 

 

다음에 알아볼 내용

what ci cd stands for?  

+ Recent posts