전체카테고리 468

특정 NameSpace에서 특정 상태의 Pod를 지우고 싶을때

가끔, Pending된 Pod 녀석들을 한꺼번에 지우고 싶을때가 있다. 근데 특정 NameSpace에서 말이다. 그럴때는 아래와 같은 CLI를 사용한다. $ kubectl get pods -n [네임스페이스 이름] | grep [지우고싶은 상태] | awk '{print $1}' | xargs kubectl delete pod -n [네임스페이스 이름] 위 처럼 해도 되고 field selector 조건을 붙여도 된다. $ kubectl delete pod -n [네임스페이스] --field-selector status.phase=[삭제할상태]

PaaS/Kubernetes 2024.01.04

Kubernetes 인증서 만료시 갱신방안

kubectl 을 돌렸더니 아래와 같이 인증서가 만료되었다는 안내가 나온다. Unable to connect to the server: x509: certificate has expired or is not yet valid: current time 2024-01-05T06:06:24+09:00 is after 2023-12-23T12:35:45Z kubeadm 으로 인증서 현황을 조회하면 아래와 같다. $ kubeadm certs check-expiration 우선 kubernetes 관련 주요 설정을 백업 해두자. $ cp -pr /etc/kubernetes/ /etc/kubernetes_backup 간단히 한꺼번에 인증서 갱신이 가능하다. $ kubeadm certs renew all Kubectl..

PaaS/Kubernetes 2024.01.04

Github Actions) Github-hosted와 self-hosted runner의 차이점

Github-hosted Runner는 간단하고 빠르게 Workflow를 운영할 수 있다. 반면에 self-hosted Runner는 당신의 환경에 맞추어 커스터마이징할수 있는 여지가 많다. GitHub-hosted runners Github으로부터 관리되는 가상환경이며 매 Job 실행마다 Clean한 인스턴스가 제공된다. 무료로 제공되는 몇분이 있고 그이후에는 분단위로 과금된다. Self-hosted runners Runner에 대한 업데이트는 비활성화하면서도 Runner 어플리케이션만 자동업데이트를 하게된다. 이러한 Runner S/W 업데이트에 대한 자세한 내용은 이 링크를 참조바란다. 그리고 직접 관리하는 로컬머신이나 Cloud 서비스에서 운영하므로 당신은 해당 OS와 관련 S/W에 대한 책임이 ..

PaaS/CI CD 2024.01.03

(Gitlab) Merge Request시 delete source branch가 체크되어 있는 경우

Gitlab에서 Merge Request시에 아래와 같이 Delete source branch ... 가 체크되어 있는 경우가 있다. 만약 조직의 DevOps 정책이 Merge해도 Branch삭제를 하지 않는것이 정책이라면 사용자 실수를 방지하는것이 중요하다. Default로 Delete Source Branch를 띄우고 싶지 않다면 아래와 같은 세팅을 하는 것이 좋다 . [해당 Project]-[General Settings]-[Merge Request] 에서 Enable "Delete source branch" ... 를 비활성화 한다.

PaaS/CI CD 2023.12.14

Gitlab 의 Project내의 특정 파일을 Access Token 만으로 접근하여 다운로드

Shell 이나 CICD Pipeline을 짜다보면 간단하게 특정 Repository의 Single File만 다운로드 받고 싶을때가 있다. 이럴때 사용하면 유용하다. 1. Gitlab에서 계정에 대한 Token을 만든다. [내 Profile]-[Edit profile]-[Access Token]-[Personal Access Token] ※ Access Token을 복사해두자! 2. 해당 Token으로 API가 정상적으로 호출되는지 테스트한다. $ curl --header "PRIVATE-TOKEN: PUT_ACCESSTOKEN_HERE" "http://gitlab.armyost.com/api/v4/personal_access_tokens" 이때 JSON Type으로 Gitlab 계정에 대한 API 토..

PaaS/CI CD 2023.12.08

Github Actions의 Workflow에서 GCP(Google Cloud Platform) 인증받기

AWS와 거의 유사하게 IAM에서 만든 Account에 OIDC 인증이 가능하도록 세팅하는 구조이다. 관련링크 : https://cloud.google.com/blog/products/identity-security/enabling-keyless-authentication-from-github-actions Enabling keyless authentication from GitHub Actions | Google Cloud Blog Authenticate from GitHub Actions to create and manage Google Cloud resources using Workload Identity Federation. cloud.google.com Github Actions 파이프라인과 샘..

PaaS/CI CD 2023.12.07

(GCP) BigQuery 에 대해서

BigQuery란? BigQuery 는 확장성이 뛰어난 구글의 기업용 서버리스 기반의 데이터 웨어하우스 입니다. 관리할 인프라가 없기 때문에 데이터 분석에 집중할 수 있으며, 인프라 및 데이터를 관리할 관리자도 필요하지 않습니다. BigQuery는 ANSI:2011을 준수하는 표준 SQL을 지원하기 때문에 기존에 SQL을 알고 있는 사용자도 손쉽게 이용할 수 있는 장점이 있으며, ODBC 및 JDBC 드라이버를 제공하여 데이터를 쉽고 빠르게 통합할 수 있습니다. BigQuery는 몇 초 만에 기가바이트급에서 페타바이트급에 이르는 데이터를 대상으로 초고속으로 SQL쿼리를 실행할 수 있습니다. 매월 무료로 최대 1TB 상당의 데이터를 분석하고 10GB의 데이터를 저장할 수 있습니다. BigQuery는 스토리..

(GCP) Cloud SQL 이란?

AWS의 RDS와 유사하다. Cloud SQL Cloud SQL은 크게 MySQL과 PostgreSQL을 제공합니다. MySQL과 MySQL용 Cloud SQL의 차이 일반적으로 Cloud SQL인스턴스에서 제공하는 MySQL 기능은 로컬에서 호스팅 되는 MySQL과 기능은 동일하지만 몇가지 차이점이 있습니다. - 지원되지 않는 기능 사용자 정의 함수 InnoDB memchached 플러그인 Federated Engine SUPER 권한 - 지원되지 않 명령문 - 지원되지 않는 클라이언트 프로그램 LOAD DATA INFILE이 제한되기 때문에 --local 옵션을 사용하지 않는 mysqlimport는 지원되지 않습니다. 원격으로 데이터를 로드해야 하는 경우 Cloud SQL import 함수를 사용해야..

(GCP) 공유 VPC란

AWS와 GCP의 주요한 다른점 하나는 Project 개념인것 같다. 그러다 보니 VPC도 Project별로 따라가는 리소스가 되어, 공유 VPC라는 개념이 나온것 같다. 공유 VPC를 사용하면 조직에서 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있습니다. 때문에 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다. 조직내 여러 프로젝트 가운데 중심이 되는 하나의 프로젝트를 '호스트 프로젝트'로 지정합니다. 이후 하나 이상의 다른 서비스 프로젝트를 여기에 연결합니다. 이때 호스트 프로젝트의 VPC 네트워크를 공유 VPC 네트워크에 연결된 다른 프로젝트들은 '서비스 프로젝트'라고 합니다. 이렇게 공유 VPC를 사용하면 조직 관리자가 서브넷, 경로, 방화벽 같은..

(GCP) GCP IAM에 대하여

GCP IAM은 전반적으로 AWS와 유사한 컨셉을 갖고 있다. GCP IAM의 정책 상속은 상→하 수준으로 내려갑니다. 즉, 리소스는 프로젝트에서 정책을 상속하고, 프로젝트는 폴더에서 정책을 상속하며, 폴더는 조직에서 정책을 상속합니다. Cloud IAM 정책 계층 구조는 GCP 리소스 계층 구조와 동일한 경로를 따릅니다. 리소스 계층 구조를 변경하면 정책 계층 구조도 변경됩니다. 예를들어, 프로젝트를 조직으로 옮기면 프로젝트의 Cloud IAM 정책이 해당 조직의 Cloud IAM 정책을 상속하도록 업데이트 됩니다. 하위 정책은 상위 수준에서 허용된 엑세스 권한을 제한할 수 없습니다. 기본역할 소유자, 편집자, 뷰어로 소유자 역할에는 편집자 역할의 권한이 포함되며, 편집자 역할에는 뷰어 권한이 포함됩니..