Monologue

A developer's monologue

aws

AWS, 네트워크 환경구축

AWS, lightsail 컨테이너 서비스에서 지원하는 것이 부족해서 ECS 를 무작정 사용해보고자 했다. (lightsail 컨테이너도 기반은 ECS 라고 하던데 세부적인 기능이 빠져있었다.) 먼저 lightsail 에서 벗어나 aws 상에 네트워크를 구축하는 것이 먼저 해야 할 일이었고 아래와 같이 VPC 를 구성하고 AZ 를 나누어 pubic / private zone의 구성을 만들어야 했다. 1. 네트워크

aws

AWS, SES 도메인 연동

개인 프로젝트를 진행하던 도중 AWS 의 Simple Email Service 를 고려하게 됐고 연동과정을 기록해 두기로 한다. 1. 자격증명생성 과감하게 오른쪽 위 "자격증명생성" 을 클릭해봤다. 생소한 화면이나 수정하면 되지 하는 마음으로 아래와 같이 대충 입력 후 "자격증명생성" "자격증명생성" 완료 후 아래와 같이 TXT 레코드 및 CNAME 레코드를 지정 하라는 메시지를 볼

golang

Golang, CGO Linux 크로스 컴파일러

* Cross Compiler 이 크로스 컴파일러는 Apple Silicon 및 Intel Mac을 모두 지원합니다. homebrew-macos-cross-toolchains/README.md at main · messense/homebrew-macos-cross-toolchainsmacOS cross compiler toolchains. Contribute to messense/homebrew-macos-cross-toolchains development by creating an account on GitHub.GitHubmessense * brew 패키지 설치 brew tap messense/macos-cross-toolchains brew install x86_64-unknown-linux-gnu brew install aarch64-unknown-linux-gnu * CrossCompile, x86_

benchmark

uvicorn 0.16.0 성능문제

cloud 에서 uvicorn 으로 서비스 해야 하는 상황에서 어떤 구조로 서비스 하는게 효율이 좋을 지 고민 중에 다음과 같은 테스트를 진행했고 뜻밖의 상황을 기록해둔다. 테스트를 마친 지금 결론은 uvicorn 의 특정버전 문제가 아닌 듯 하다. uvicorn 이 worker 프로세스를 제어하는 방식(spawn)에서 파생된 문제로 보인다. (그렇다고 하기에도 워커가 1개일때도

python, db library benchmark (feat. sqlalchemy vs aiomysql)
benchmark

python, db library benchmark (feat. sqlalchemy vs aiomysql)

DB 라이브러리에서 동기처리 (sqlalchemy) 가 비동기처리 (aiomysql) 특성에 따라 어떤 차이가 있는 지 살펴봤다. 벤치마크 테스트는 Pool 을 구성하고 주요 옵션이나 기능의 차이를 살펴보고자 했다. 기본적으로 동기처리는 Pool 에서 하나씩 Connection을 사용하고 리턴하는 방식으로 처리 될 것이며, 비동기 처리는 비동기로 날라오는 요청들을 가능한 Pool 안의 Connection을 가져다 쓰고 리턴하는 방식을

FastAPI, CRUD API 개발을 위한 기록
python

FastAPI, CRUD API 개발을 위한 기록

API에 있어 기본이 되는 CRUD API 를 개발하며 FastAPI 에 적응하기 위한 기록을 남긴다. 1. 환경세팅 1) 프로젝트 생성 poetry new apps poetry 를 통해 프로젝트를 생성하면 아래와 같은 구조를 갖게 된다. apps ├── pyproject.toml ├── README.rst ├── apps │ └── __init__.py └── tests ├── __init__.py └── test_apps.py 2) 의존성 라이브러리 설치

trouble shooting

minikube(feat. lima) 환경에서 로컬 이미지를 가져오지 못하는 문제

개발한 어플리케이션 이미지를 지난 글에서 구축한 minikube  환경에 올려 보고자 하면서 문제를 발견했다. 환경정보 * silicon m1 mac * minikube version v1.24.0 * limactl 0.7.4 로컬에서 빌드한 이미지를 minikube 환경으로 가져 오려면, 가장 간단한 방법이 도커 host 와 minikube 를 연결하는 방법인데 다음과 같이 containerd runtime 은 지원이 안되는

ASGI 웹 프레임워크 FastAPI  를 시작하며
python

ASGI 웹 프레임워크 FastAPI 를 시작하며

Python, Backend 를 시작하는 데 부족한 부분들을 정리해 보고자 한다. 1. Backend 구성 (feat. WSGI 와 ASGI) Python 의 일반적인 웹서비스에 아키텍쳐를 이해하기 위해 아래와 같은 그림을 그려봤다. 1) Web Server 웹서버의 역할은 두개로 나누어 볼 수 있다. 정적인 요청의 서빙이나 Reverse Proxy를 이용하여 어플리케이션 서버로 동적인 요청을 전달하는 용도이다.

Slicon M1 Mac에 Conda 가상환경 만들기 (feat. miniforge)
python

Slicon M1 Mac에 Conda 가상환경 만들기 (feat. miniforge)

conda는 주로 Python의 버전별 가상환경과 의존성이나 패키지를 관리하는 툴입니다. 간단하게 생각하면 패키지 매니저이면서 파이썬의 버전을 골라 설치 할 수도 있는 툴이라고 보면 된다. 대표적인 conda 환경을 만들어주는 프로그램은 Anaconda(anaconda 채널), miniconda(anaconda 채널), miniforge(conda-forge 커뮤니티 채널)가 있고, Anaconda는 5G 정도 되는 패키지를 동시에 설치하는 다소 무거운 환경을

Slicon M1 Mac에서 쿠버네티스 환경 구축하기 (feat. lima+minikube)
kubernetes

Slicon M1 Mac에서 쿠버네티스 환경 구축하기 (feat. lima+minikube)

지난 글 에서는 Lima 를 활용하여 docker 개발환경을 구축해 보았고 이번에는 lima 를 minikube의 드라이버로 설정하여 쿠버네티스 개발환경을 구축해보기로 했다. 1. Lima 구동 limactl start export DOCKER_HOST=unix://$HOME/docker.sock docker ps 2. minikube 설치 brew install minikube # docker 드라이버에 containerd를 컨테이너 런타임으로 사용하여 kube 환경구축 minikube start

Silicon M1 Mac에서 UTM으로 Docker Desktop 대체 하기
docker

Silicon M1 Mac에서 UTM으로 Docker Desktop 대체 하기

이 글은 꽤 오래된 글이고 현재 (23년 10월) 는 OrbStack · Fast, light, simple Docker & Linux on macOS 라는 툴을 쓰는 것을 권장한다. Docker Desktop 의 유료전환 소식이 있었고 22년 1월 말까지 유예기간을 둔다고 한다. 그 성능이 어떠하든 개발환경을 구축할때 필수적으로 사용하던 어플리케이션이라 아쉬움이 많이 남는다. Mac 환경에서 개발을 해야하는 회사들은

Makefile

ShellScript 와 Makefile

이번에 ShellScript 와 같이 정리해보려는 Makefile 의 경우, 보통 C 로 작성된 소스를 의존성을 기술하여 make 라는 명령어로 컴파일을 도와주는 스크립트다. 요즘 go 에서 makefile 을 활용하는 몇가지 글들을 접하면서 ShellScript 보다 체계적이고 깔끔하게 느껴져서 이제는 대부분을 makefile 로 자동화 작업을 하고 있다. 이 글에서는 ShellScript 와 Makefile 어느 것이

go versioning

Go 패키지 생성에서 버전관리 까지

GitHub 에서의 go 프로젝트 생성과 versioning 과정을 코드로 정리해 보고자 한다. 유의적 버전 2.0.0 | Semantic Versioning https://github.com/golang-standards/project-layout Semantic 버전관리 Go에서는 패키지 버저닝을 위해 Semantic Versioning을 사용하길 제안하고 있으며, 간단하게 정리를 하자면 다음과 같다. * ~기존 버전과 비호환~ 되며 API가 바뀌면 “MAJOR 버전”을 올리고, * ~기존