Pentaho ETL
최근 Jasper 유사한 ETL도구가 필요한 상황이 되어 찾아보다 발견한 Pentaho Data Integration을 테스트 하고 있다.
Jasper보다 나중에 만들어졌고 나름 깔끔하다.
duckdb + excel
SELECT current_setting('extension_directory');
SELECT * FROM pragma_version();
SELECT duckdb_version();
# extension 상태를 볼 수 있다.
SELECT * FROM duckdb_extensions();
INSTALL 'excel';
LOAD 'excel';
select * from read_xlsx('file_example_XLSX_5000.xlsx');
select * from read_excel('file_example_XLSX_5000.xlsx');
Excel을 읽어서 sqlite에 넣으려다 왠지 있을것같아 찾아보니 있다.
duckdb에 excel을(csv가 아니다) 직접 읽을수 있는 방법을 찾아보니 있다.
다만, 이 녀석 여러가지 버전관련 설정을 타는지, duckdb_version() 명령은 안 되고, pragma_version()으로 확인 했을 때 v1.3.0에서 read_xlsx() 명령으로 작동하는 것을 확인한다.
즉, 자신의 상황에따라 이것 저것 점검 할 것이 많다는 뜻일수있다.
WSL에서 방화벽 열기
New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow
New-NetFirewallRule -DisplayName "WSL2-MySQL" -Direction Inbound -LocalPort 3306 -Action Allow -Protocol TCP
WSL2에 설치된 서비스가 Windows에서 접속되지 않는 현상 점검 방법
WSL2(Windows Subsystem for Linux 2)에서 실행 중인 웹 서버, 데이터베이스 등 리눅스 서비스가 Windows(호스트)에서 접속되지 않을 때 점검해야 할 주요 항목과 해결 방법을 정리합니다.
1. 네트워크 구조 이해
- WSL1은 Windows와 네트워크를 공유(로컬호스트 사용)하지만,
- WSL2는 NAT 기반 가상 네트워크를 사용하여 별도의 내부 IP를 가집니다. 이 때문에 WSL2에서 실행한 서비스는 기본적으로 WSL2 내부 IP에서만 접근 가능하며, Windows에서 바로 접근이 안 될 수 있습니다123.
2. 서비스 바인딩 주소 확인
- 리눅스 서비스(예: 웹 서버)가
127.0.0.1(localhost)에만 바인딩되어 있으면 WSL2 내부에서만 접근 가능합니다. - 반드시 0.0.0.0 또는 WSL2의 내부 IP로 바인딩해야 Windows에서 접근할 수 있습니다.
예시 (Flask):
Test-NetConnection
Test-NetConnection -ComputerName localhost -Port 31143
어쩔수 없이 Win10을 사용하게되면서 PowerShell을 조금씩 써보고있다.
Content-Disposition
Content-Disposition 설명
Content-Disposition은 HTTP 응답 헤더 중 하나로, 서버가 클라이언트(주로 웹 브라우저)에게 전송하는 콘텐츠를 어떻게 처리할지 지시하는 역할을 합니다. 주로 파일 다운로드, 인라인 표시, 멀티파트 폼 데이터 처리 등에서 사용됩니다12345.
주요 용도 및 형식
1. 인라인 표시(기본값)
2. 첨부파일 다운로드
Content-Disposition: attachment- 브라우저가 콘텐츠를 다운로드하도록 유도합니다.
- 파일명을 명시할 수 있습니다.
Content-Disposition: attachment; filename="example.pdf"
3. 멀티파트 폼 데이터
- 파일 업로드/폼 전송 등에서 각 파트의 이름과 파일명을 지정할 때 사용합니다.
Content-Disposition: form-data; name="field1"
Content-Disposition: form-data; name="file"; filename="example.txt"
파일명 인코딩
- 파일명에 한글 등 비ASCII 문자가 포함된 경우, 다음과 같이 인코딩하여 전달할 수 있습니다.
Content-Disposition: attachment; filename*=UTF-8''%ED%95%9C%EA%B8%80.pdf
filename*파라미터와 URL 인코딩을 활용합니다4.
실제 사용 예시
- 서버에서 파일 다운로드 응답을 보낼 때:
Content-Disposition: attachment; filename="report.xlsx"
→ 브라우저는 파일을 자동으로 다운로드하고, 파일명을 report.xlsx로 지정합니다.
email + eml + sync
# EML 파일명을 Maildir 규칙에 맞게 변경 (예: 타임스탬프 활용)
for eml in *.eml; do
new_name=$(date +%s%N).$(hostname).eml
cp "$eml" "/tmp/maildir/new/$new_name"
done
어쩌다 보니 이메일을 파싱해서 특정 보험건에 대한 요율을 추출해야 하는 상황이되어 제반 준비를 하다 발견했다.
위 shell에서 “date +%s%N"의 의미를 몰라 찾아보니.
date 명령의 형식을 지정하는 파라미터였다. 음. 위 방식을 unix 나노초를 반환하는 것이다.
그런데 뒤쪽의 hostname은 왜 필요한 것일까? (그냥 식별하는 용으로 보인다.)
gcp + apigee + SpikeArrest
![]() |
|---|
| SpikeArrest works |
apigee의 traffic management를 보다가 생각한다.
그 짧은 순간에 이전과 이후의 요청을 어떻게 구분한 것인지 말이다.
구글의 엔지니어들은 양동이 개념을 도입해서 요청이 들어오면 평가하는 것이 아니라, 각 요청들을 하나의 양동이에 담고, 그 양동이 시간이 되면 퍼내는 식으로 구현을 했다.
참고할 만하다.
Win 시계가 자꾸만 틀림.
시스템을 설치하고 Window로 부팅하는 경우 시간이 자꾸 틀려서(==동기화가 안 되어서) MS가 다되었다 생각하고 있었는데 말이다.
오늘 몇 달만에 Window로 부팅을 했더니, 시간이 꼭 UTC라는 느낌이 들어 분을 보니 동일하다.
윈도우와 리눅스 듀얼부트 환경 대부분의 리눅스 배포판은 하드웨어(메인보드) 시계를 UTC로 저장하는 반면, 윈도우는 기본적으로 하드웨어 시계를 로컬 타임(한국 기준 KST 등)으로 간주합니다. 이로 인해 두 운영체제를 번갈아 부팅할 때 시간이 맞지 않거나, 윈도우에서 시간이 UTC 기준으로 표시되는 문제가 발생할 수 있습니다
그렇다고 합니다. 딱히 수정할 생각은 없다.
sops + container
SOPS를 Docker에 포함하는 대표적 사례
SOPS(Secrets OPerationS)는 Docker 환경에서 다양한 방식으로 통합·활용되고 있습니다. 아래는 실제 사례와 구현 방법, 그리고 주요 활용 패턴을 정리한 내용입니다.
1. SOPS 바이너리 내장 Docker 이미지 생성
- 방법: Dockerfile에서 SOPS 바이너리를 직접 다운로드해 이미지에 포함시킵니다.
- 예시:
FROM alpine:latest
# SOPS 설치
RUN wget https://github.com/mozilla/sops/releases/download/v3.8.1/sops-v3.8.1.linux.amd64 -O /usr/local/bin/sops \
&& chmod +x /usr/local/bin/sops
# age(옵션) 설치
RUN wget https://github.com/FiloSottile/age/releases/download/v1.1.1/age-v1.1.1-linux-amd64.tar.gz -O /usr/local/bin/age \
&& chmod +x /usr/local/bin/age
# 필요에 따라 키 파일, 설정 파일 등을 COPY
COPY ./src/generate_sops_config.sh /app/config/generate_sops_config.sh
RUN chmod +x /app/config/generate_sops_config.sh
# 추가적으로 키 생성, .sops.yaml 생성 등 스크립트 실행 가능
ENTRYPOINT ["sops"]
2. SOPS를 활용한 컨테이너 환경변수 주입
- 방법: SOPS의
exec-env기능을 활용하여, 암호화된 시크릿 파일을 복호화해 Docker 컨테이너에 환경변수로 주입합니다. - 예시:
sops exec-env secret.enc.json 'docker run --rm -it -e PASSWORD_1=$PASSWORD_1 alpine sh -c "echo $PASSWORD_1"'
- `secret.enc.json` 파일을 복호화해 환경변수로 만들고, 해당 환경변수를 컨테이너에 전달합니다.
- Docker Compose 연동:
sops exec-env secret.enc.json 'docker compose up'
- 환경변수는 오직 해당 프로세스에서만 유효하며, 안전하게 임시로 전달됩니다[^4].
3. SOPS + HashiCorp Vault 등 외부 시크릿 관리와 연동
- 방법: Vault, AWS KMS, GCP KMS 등 외부 시크릿 관리 시스템과 SOPS를 연동하여, Docker 컨테이너에서 안전하게 시크릿을 복호화·활용합니다.
- 예시: Vault를 Docker 컨테이너로 띄우고, SOPS가 Vault의 키로 시크릿을 암호화/복호화하도록 설정3.
4. .sops.yaml로 파일별 암호화 정책 자동화
- 방법:
.sops.yaml파일을 Docker 이미지에 포함시키거나, 볼륨 마운트로 전달하여 환경별(예: dev, prod)로 각기 다른 KMS 키, PGP 키 등을 자동 지정할 수 있습니다. - 예시:
creation_rules:
- path_regex: \.dev\.yaml$
kms: "arn:aws:kms:us-east-1:111111111111:key/xxx-xxx-xxx"
- path_regex: \.prod\.yaml$
kms: "arn:aws:kms:us-east-1:111111111111:key/yyy-yyy-yyy"
- pgp: "A2B73FB4DA0891B38EECD35B47991CD146C9C4BC"
- 파일명 패턴에 따라 자동으로 암호화 키를 선택[^5].
5. 실전 활용 패턴
- CI/CD 파이프라인: SOPS 내장 이미지를 사용해 빌드/배포 과정에서 시크릿 복호화 및 환경변수 주입 자동화
- 로컬 개발/운영 환경: SOPS 내장 컨테이너로 시크릿 파일 관리, 복호화, 테스트 일관성 확보
- 컨테이너화된 시크릿 관리: SOPS를 포함한 컨테이너를 별도의 유틸리티로 활용, 필요 시 볼륨 마운트로 시크릿 파일 주입
요약
- SOPS는 Docker 이미지에 바이너리로 포함해 사용할 수 있으며, 환경변수 주입, 시크릿 복호화, 외부 시크릿 관리 시스템과의 연동 등 다양한 활용 사례가 있습니다.
sops exec-env를 통한 환경변수 주입,.sops.yaml로 파일별 암호화 정책 지정, Vault 등 외부 서비스와의 연동이 대표적입니다.- CI/CD, 개발, 운영 등 다양한 환경에서 SOPS 내장 Docker 이미지를 활용하면 시크릿 관리의 일관성과 보안성을 크게 높일 수 있습니다1243.
JWT +JWS
JWT와 JWS 비교
| 구분 | JWT (JSON Web Token) | JWS (JSON Web Signature) |
|---|---|---|
| 정의 | JSON 형식의 claims(정보)를 안전하게 표현하는 토큰 포맷 | 데이터(주로 JWT)를 디지털 서명으로 무결성 보호하는 방식 |
| 구조 | Header, Payload, (Signature 또는 암호화) | Header, Payload, Signature |
| 목적 | 정보(Claims) 전달 및 인증/인가 등 | 데이터 위변조 방지(무결성 보장) |
| 서명/암호화 | 서명(JWS), 암호화(JWE), 둘 다 또는 없음 가능 | 반드시 서명만 지원, 암호화는 지원하지 않음 |
| Payload 형식 | 반드시 JSON 객체 | 어떤 바이너리든 가능(JSON, 바이너리, 텍스트 등) |
| 사용 예시 | 인증 토큰, 정보 전달 등 | JWT의 서명, 일반 데이터의 서명 등 |
상세 설명
- JWT란? JWT는 JSON 객체로 구성된 claims(정보 묶음)을 안전하게 표현하는 표준 포맷입니다. JWT는 서명(JWS 구조) 또는 암호화(JWE 구조)를 통해 무결성 또는 기밀성을 보장할 수 있습니다. 즉, JWT는 JWS 또는 JWE 구조로 만들어질 수 있으며, 가장 일반적인 JWT는 JWS 구조(서명된 JWT)입니다1234.
- JWS란? JWS는 데이터(주로 JWT의 payload)를 디지털 서명하여, 위변조되지 않았음을 증명하는 표준입니다. JWS는 Header, Payload, Signature 세 부분으로 구성되며, 서명 알고리즘(HMAC, RSA, ECDSA 등)을 사용합니다. JWS의 Payload는 반드시 JSON일 필요는 없으며, 바이너리 등 다양한 형식이 가능합니다1534.
- 관계
- 보안성
- JWS는 서명만 지원하므로, 누구나 Payload를 볼 수 있지만 위변조 여부는 검증 가능합니다.
- JWE는 암호화를 통해 Payload 자체를 숨길 수 있습니다3.
요약
- JWT는 정보를 안전하게 표현하는 “컨테이너"이며,
- JWS는 그 컨테이너(혹은 임의의 데이터)에 “서명"을 부여하는 방식입니다.
- JWT의 가장 흔한 구현이 JWS 구조(서명된 JWT)입니다.
- JWS는 JSON뿐 아니라 다양한 데이터 형식을 서명할 수 있습니다134.
