devops

우리 팀에서는 실제 여러 클라우드 환경에서 서비스를 운영, 테스트하고 있기 때문에 서비스 별로 각기 다른 config 파일을 관리해야 한다. 처음엔 환경마다 Parameter store를 이용해 파일과 key들을 관리했지만 환경에 접속해서 매번 수정하는 게 아주 번거로웠다. 특히나 github action에서 action을 위한 secret 환경변수도 레포마다 관리하는 것이 쉽지 않았다. 이렇게 흩어져있는 설정 파일 혹은 key값들을 중앙화시킬 필요가 있었고, 쿠버네티스를 사용하기 때문에 모든 환경에서 작동하는 컴포넌트의 배포 상태와 흐름을 파악할 수 있어야 했다. 이 요구사항들을 바탕으로 Vault, ECR, ArgoCD가 사용되는 Github action CICD 파이프라인을 구축하게 되었다. EKS..

Vault의 시크릿 엔진은 data를 암호화하고 저장하고 생성하는, 어떤 기능을 하는 유연한 특징을 가진 컴포넌트로 보면된다. 어떤 시크릿 엔진은 단순히 데이터 저장과 읽기만 제공하지만, 어떤 것은 서비스와 연결되어 동적인 Credential을 생성하기도 하고 인증 역할을 하기도 한다. 모든 시크릿 엔진은 볼트의 path를 통해서 활성화된다. 그래서 볼트에 요청이 올때 자동으로 해당 경로로 라우팅되어 처리된다. 시크릿 엔진은 개별 경로(path)와 속성이 정해져있기 때문에 사용하는 유저입장에서는 Virtual Filesystem이라고도 볼 수 있음 Lifecycle Enable : 시크릿 엔진의 경로와 함께 Enable된다. (몇몇 시크릿 엔진은 여러 경로로 Enable이 될 수 있음) 각 시크릿 엔진은..

ServiceAccount에 적용된 Role의 신뢰관계 설정 문제일 가능성이 크다. ServiceAccount가 AWS 리소스에 접근할 권한이 없기 때문. $ kubectl describe sa aws-load-balancer-controller -n kube-system 먼저 ALB Controller의 SA를 상세 정보를 확인하면, 위와 같이 Annotation에 선언된 Role을 확인할 수 있음. 위에선 AmazonEKSLoadBalancerControllerRole이 SA의 Role로 선언되어 있음. AmazonEKSLoadBalancerControllerRole을 확인해보면 아래와 같은 신뢰관계가 구성되어있다. { "Version": "2012-10-17", "Statement": [ { "Ef..

Ingress 동작 방식 ALB Controller는 API 서버의 Ingress 이벤트를 모니터링한다. 요구 사항을 충족하는 수신 리소스 발견 시, AWS 리소스 생성을 시작한다. 수신 리소스에 맞춰 AWS에서 ALB(ELB v2)를 생성한다.(이 ALB는 인터넷 연결이 되거나 내부에 존재할 수 있으며 Annotation으로 서브넷 지정 가능) Target Group은 수신 리소스에서 지정된 고유 k8s 서비스에 대해 AWS에서 생성된다. 수신 리소스의 Annotation에 설명된 모든 포트에 대해 리스너가 생성된다. 포트는 80과 443이 디폴트며, Annotation에 인증서 첨부도 가능하다. 수신 리소스에 각 경로에 대한 규칙이 생성된다. 특정 경로에 대한 트래픽이 적절한 k9s 서비스로 라우팅된..

L2의 핵심 중 하나는 L1 자산의 이동이 가능한 'Bridge'다. 이 Bridge를 위한 레이어간 메시지는 L1의 컨트랙트와 L2 컨트랙트 간의 호출을 말한다. 쉽게 말해서 크로스체인 컨트랙트 콜이다. 원활한 메시지 송수신을 위해서 L1과 L2에 여러 컨트랙트를 배포해야한다. 이 컨트랙트들의 역할과 원리를 간단히 살펴보자. L1 → L2 Contract 메시지 L1에서 L2로 메시지를 전달하려면, 함수를 호출하는데, 먼저 L1의 Inbox를 거쳐서 Bridge를 거쳐야한다. 여기서 L2의 alias Account는 L1 컨트랙트의 Account다. 그래서 L2 Contact 호출하는 것은 L2 네트워크의 alias Account에서 시작하며, 호출에 의한 트랜잭션 수수료도 부과된다. L1에서 L2로 ..

Layer 2를 구축하기 위해선 L1과 동시에 몇가지 Contract를 배포해야한다. OP stack으로 테스트하는 과정에서도 먼저 L1에 여러 contract를 배포하는데, 생각보다 배포되는 게 많다. L1에 배포되는 컨트랙트는 L2와 오프체인에서 계산된 Tx, 결과값(State)가 저장되는데 주로 사용된고, L2는 L1과의 매핑 혹은 연결과 수수료에 관련된 컨트랙트들이 배포된다고 볼 수 있다. 그도 그럴 것이, L1의 보안(데이터 가용성)을 위한 컨트랙트와 이를 바라보는 L2의 증명, 확인이 중요하기 때문. 이 Contract들의 역할과 구성을 알아보면, 좀 더 구체적으로 Layer2가 어떻게 작동하는지 이해할 수 있기 때문에 한번 정리해보려 한다. (코드는 파헤치는건 다음에...) 배포되는 컨트랙트..

지난 OP stack에 대한 간단한 정리글에 이어, 이번에는 OP stack으로 Wemix3.0의 Layer 2를 구축하는 테스트를 진행하려고 한다. Wemix 3.0 Testnet 정보 : https://metaschool.so/rpc/wEMIX3.0Testnet 공식문서에는 Goerli Testnet으로 설정되어 있지만, Goerli는 ETH를 받기가 굉장히 까다롭고 번거로워서 Wemix 테스트넷으로 변경했다. 그 과정에서 약간의 수정 작업이 요구된다. Prerequisites - Ubuntu 20.04 LTS $ sudo apt install -y git curl make jq $ sudo apt update $ wget https://go.dev/dl/go1.20.linux-amd64.tar.gz..

블록체인의 트릴레마는 해결하기보다 Layer 2가 트릴레마를 보완해 가는 방향으로 발전하고 있다고 생각한다. 현재 많은 Layer 2들이 활동하고 있지만 Optimism은 자체 Layer와 더불어 이더리움 기반의 새로운 Layer2 생태계를 그려나가고 있다. 그 시작은 OP stack이라는 Layer 2 SDK다. OP stack 공식 문서 내용을 보면, OP stack은 Optimism Superchain과 거버넌스를 위한 소프트웨어 세트라고도 말한다. 여기서 Superchain은 OP stack을 기반으로 레이어간의 통신과 보안, 거버넌스를 공유하는 네트워크다 Utility, Simplicity, Extensibility OP stack은 3가지 원칙에 따라 구축된다. 유틸리티와 간단함 그리고 확장성..