반응형

Burrow 는 또한 링크드인에서 제작한 아파치 카프카용 컨슈머 lag 를 체크하기 위한 api 서비스이다.

 

kafka 에 대한 endpoint 정보를 burrow 에 적용을 하면 카프카 lag 에 대한 정보부터 다양한 정보를 api 로 제공 받을 수 있다.

이 정보들을 활용해서 로그로 적재할 수 도 있다

 

 

공식문서

https://github.com/linkedin/Burrow

 

GitHub - linkedin/Burrow: Kafka Consumer Lag Checking

Kafka Consumer Lag Checking. Contribute to linkedin/Burrow development by creating an account on GitHub.

github.com

 

 

burrow 설치 

먼저 burrow 를 설치전에 go 를 설치해야 한다. burrow 는 go 로 만들어져 있다.

 

go 설치

brew install go

및 go 사이트에서 다운받아서 사용하면 된다.

 

git 레포지토리 clone

$ git clone https://github.com/linkedin/Burrow.git

 

go 실행하여 Burrow.exe 생성

클론 받은 디렉토리로 이동하고 go mod tidy 및 go install 을 해라. 

그러면 go 가 설치면 디렉토리에 go 하위 폴더에 Burrow.exe 가 생겼을 거다.

나 같은 경우 mac 

/Users/사용자명/go/bin 에 생성됐다.

$ cd to the source directory.
$ go mod tidy
$ go install

 

 

설정파일 수정

실행 전에 설정파일을 수정해야 한다.

파일명 burrow.toml 이고 git clone 으로 파일 repo 의 config 폴더에 있다.

[general]

[logging]
level="info"

[zookeeper]
servers=[ "localhost:2181"]

[client-profile.local]
client-id="burrow-local"
kafka-version="2.0.0"

[cluster.local]
class-name="kafka"
servers=[ "localhost:9092" ]
client-profile="local"
topic-refresh=120
offset-refresh=30

[consumer.local]
class-name="kafka"
cluster="local"
servers=[ "localhost:9092" ]
client-profile="local"
group-denylist="^(console-consumer-|python-kafka-consumer-|quick-).*$"
group-allowlist=""

[httpserver.default]
address=":8000"

[storage.default]
class-name="inmemory"
workers=20
intervals=15
expire-group=604800
min-distance=1

설정값들에 대한 정리는 여기 정리가 되어 있다.

https://gunju-ko.github.io/kafka/2018/06/06/Burrow.html

 

Monitoring Consumer LAG - Burrow

Burrow Burrow - Kafka Consumer Lag Checking Burrow는 카프카의 모니터링 툴로 Consumer의 LAG을 모니터링할 때 주로 사용된다. 모든 Consumer의 커밋 오프셋을 모니터링한다. 또한 필요할 때 Consumer의 상태를 계산

gunju-ko.github.io

 

실행

git clone 받은 repo로 이동 후 아래와 같이 Burrow.exe 파일로 수정한 config 파일을 읽어 실행하면 된다.

$ /Users/사용자명/bin/Burrow --config-dir=/config

 

서비스 확인은 

localhost:8000/burrow/admin 을 띄우면 GOOD 이 뜬다.

 

엔드포인트 정리된 문서는

https://github.com/linkedin/Burrow/wiki/HTTP-Endpoint

 

GitHub - linkedin/Burrow: Kafka Consumer Lag Checking

Kafka Consumer Lag Checking. Contribute to linkedin/Burrow development by creating an account on GitHub.

github.com

 

반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
telegraf 시작하기  (0) 2022.01.04
ZIPKIN 시작하기  (0) 2021.11.25
프로메테우스 Prometheus 시작하기(docker)  (0) 2021.11.04
반응형

Zipkin 설치방법 1(Jar 파일 실행)

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

Zipkin Elasitc 저장소로 실행

java -jar zipkin.jar --STORAGE_TYPE=elasticsearch --ES_HOSTS=http://127.0.0.1:9200

 

Zipkin 설치방법 2(도커 이미지 실행)

docker run -d -p 9411:9411 openzipkin/zipkin

docker-compose.yml

version: "3.3" # 파일 규격 버전
services: # 이 항목 밑에 실행하려는 컨테이너 들을 정의

  zipkin:
    image: openzipkin/zipkin
    container_name: zipkin
    # environment:
    #   - STORAGE_TYPE=elasticsearch
    #   - ES_HOSTS=localhost:9200 ## 도커로 엘라스틱 저장소 연결하는거는 다음처럼 했을때 안됐음.
    ports:
      - "9411:9411"

Zipkin 설치방법 3(zipkin-server 용 어플리케이션 생성)

@EnableZipkinServer 추가

 

 

위와 같은 준비가 끝났으면 spring 에서는 

spring cloud slueth 연동

 

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
spring:
  application:
    name: zipkin-client
  sleuth:
    sampler:
      probability: 1.0
  zipkin:
    base-url: http://localhost:9411

 

 

Zipkin 구조도

Zipkin은 크게 Zipkin Client Library와 Zipkin Server로 구성되며, Zipkin Server는 Collector, Storage, API(Query Service), Web UI(Dashboard)로 구성된다.

 

1. Zipkin Client Library : 서비스에서 트레이스 정보를 수집하여 Zipkin Server의 Collector 모듈로 전송하며, 지원하는 언어는 Java, Javascript, Go, C# 등이 있다. Collector로 전송할 때는 다양한 프로토콜을 사용할 수 있지만 일반적으로 HTTP를 사용하고, 시스템이 클 경우 Kafka 큐를 통해서도 전송을 한다.

2. Collector : Zipkin Client Library로부터 전달된 트레이스 정보 유효성을 검증하고 검색 가능하게 저장 및 색인화 한다. 

3. Storage : Zkipkin Collector로 보내진 트레이스 정보는 Storage에 저장된다. Zipkin은 초창기에는 Cassandra에 데이터를 저장하도록 만들어졌지만(Cassandra가 확장 가능하고 유연한 스키마를 가지고 있기 때문에 Twitter 내에서 많이 사용되었음), 그 뒤로 ElasticSearch나 MySQL도 지원 가능하게 구성되었다. 그 외에 In-Memory도 지원 가능하기 때문에 간단히 로컬에서 테스트할 때는 In-Memory, 소규모는 MySQL, 운영환경에 적용은 Cassandra나 ElasticSearch를 저장소로 사용하는 것이 좋다. 

4. API(Zipkin Query Service) : 저장되고 색인화된 트레이스 정보를 검색하기 위한 JSON API이며, 주로 Web UI에서 호출된다.

5. Web UI : 수집된 트레이스 정보를 확인할 수 있는 GUI로 만들어진 대쉬보드이며, 서비스 / 시간 / 어노테이션 기반으로 데이터 확인이 가능하다. Zipkin 서버의 대쉬보드를 사용할 수도 있고, ElasticSearch 백앤드를 이용한 경우는 Kibana 활용도 가능하다.

 

 

Spring Cloud Sleuth란?

MSA환경에서 클라이언트의 호출은 내부적으로 여러 마이크로서비스를 거쳐서 일어나기 때문에 추적이 어렵다. 때문에 이를 추적하기 위해서는 연관된 ID가 필요한데, 이런 ID를 자동으로 생성해주는 것이 Spring Cloud Sleuth이다.

Spring Cloud Sleuth는 Spring에서 공식적으로 지원하는 Zipkin Client Library로 Spring과의 연동이 매우 쉬우며, 호출되는 서비스에 Trace(추적) ID와 Span(구간) ID를 부여한다. Trace ID는 클라이언트 호출의 시작부터 끝날때까지 동일한 ID로 처리되며, Span ID는 마이크로서비스당 1개의 ID가 부여된다. 이 두 ID를 활용하면 클라이언트 호출을 쉽게 추적할 수 있다.


Zipkin 헤더

Zipkin은 B3-Propagation을 통해서 OpenTracing을 구현하고 있습니다. B3 propagation은 간단히 말해 ‘X-B3-‘으로 시작하는 X-B3-TraceId와 X-B3-ParentSpanId, X-B3-SpanId, X-B3-Sampled, 이 4개 값을 전달하는 것을 통해서 트레이스 정보를 관리합니다. 서버에서는 이 값들을 TraceContext에서 관리하는데요. Spring 프레임워크와 SLF4J(Simple Logging Facade for Java)를 사용하고 있었기에 MDC(Mapped Diagnostic Context)에서 해당 값을 꺼내서 사용할 수 있었습니다. HTTP를 통해 다른 서버로 전달하는 경우에는 HTTP 헤더를 통해서 전달하고, Kafka 메시지를 통해 전달하는 경우에는 Kafka 헤더를 통해서 전달합니다.

 

Spring cloud sleuth

Zipkin의 Brave는 B3-propagation의 Java 구현체이고, Spring Cloud Sleuth는 BraveTracer를 Spring 프레임워크에서 쉽게 사용하기 위한 라이브러리입니다. TaskExecutor와 RestTemplate, KafkaTemplate, KafkaListener, RedisTemplate을 사용하는 것만으로 새로운 스팬(span)이 생성됩니다. 다만, BeanPostProcessor를 통해서 동작하기 때문에 아래와 같이 메서드 내부에서 생성된 오브젝트를 사용하는 경우에는 동작하지 않는다.

 

TaskExecutor executor = new TaskExecutor();
-> 
@Bean

 

public TaskExecutor taskExecutor() { return new TaskExecutor();}
반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
telegraf 시작하기  (0) 2022.01.04
Burrow 시작하기  (0) 2021.12.30
프로메테우스 Prometheus 시작하기(docker)  (0) 2021.11.04
반응형

프로메테우스란 - prometheus 란

오픈소스 모니터링 툴로 지표 수집을 통한 모니터링이 주요 기능이다. 쿠버네티스 뿐만 아니라 애플리케이션이나 서버, OS등 다양한 대상으로부터 지표(Metric)를 수집하여 모니터링 할 수 있다. 기본적으로 Pull 방식으로 데이터를 수집하는데, 이 말은 모니터링 대상이 되는 자원이 지표정보를 프로메테우스로 보내는 것이 아니라, 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽어온다는 뜻이다(Push 방식으로 지표를 수집하는 모니터링 툴은 ELK스택 또는 Telegraf & InfluxDB 등이 있다). Pull 방식으로 지표정보를 읽어올때는 각 서버에 설치된 Exporter를 통해서 정보를 읽어오며, 배치나 스케쥴 작업의 경우에는 필요한 경우에만 떠 있다가 작업이 끝나면 사라지기 때문에 Pull 방식으로 데이터 수집이 어렵다. 그럴 경우 Push방식을 사용하는 Push gateway를 통해 지표정보를 받아오는 경우도 있다. 서버의 갯수가 정해져 있다면 프로메테우스에서 모니터링 대상을 관리하는데 어려움이 없지만, 오토스케일링이 많이 사용되는 클라우드 환경이나 쿠버네티스 클러스터에서는 모니터링 대상의 IP가 동적으로 변경되기 때문에 이를 일일이 설정파일에 넣는데 한계가 있다. 이러한 문제를 해결하기 위해 프로메테우스는 DNS나 Consul, etcd와 같은 다양한 서비스 디스커버리 서비스와 연동을 통해 모니터링 목록을 가지고 모니터링을 수행한다.

 

 

version: "3.3" # 파일 규격 버전
services: # 이 항목 밑에 실행하려는 컨테이너 들을 정의
  prometheus: # 서비스 명
    image: prom/prometheus      # 사용할 이미지
      # restart: always
    container_name: prometheus # 컨테이너 이름 설정
    ports:
      - "9090:9090" # 접근 포트 설정 (컨테이너 외부:컨테이너 내부)
    volumes:
      - /Users/폴더명/docker_voluems/prometheus/data/prometheus:/prometheus
    command: --web.enable-lifecycle --config.file=/etc/prometheus/prometheus.yml

 

프로메테우스 설정

프로메테우스 도커 접속

docker exec -it 도커명 /bin/sh

프로메테우스 내부 prometheus.yml 설정

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Def
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'eva
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scrap
  - job_name: 'spring-boot-app'
    metrics_path: '/actuator/prometheus'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['host.docker.internal:8080']

  - job_name: 'spring-boot-app'
    metrics_path: '/actuator/prometheus' 
이부분은 스프링 actuator 과 연동시킬때 사용.

scrape_configs 는 데이터를 수집할 곳의 job 정보를 작성.

위의 예시는 내부에서 사용하는 8080 포트로 시작하는 spring boot 의 정보를 스크랩한다. 

도커로 프로메테우스를 실행하고 내부 localhost 라면 tarets 을 host.docker.internal 로 설정해야 함.

 

Configuration prometheus.yml 기본 spring boot 와 설정.

targets에 모니터링할 Spring Boot 애플리케이션 IP:Port 추가
Service Discovery를 사용한다면 관련 Service Discovery 설정 추가

global:
  scrape_interval: "15s"
  evaluation_interval: "15s"
scrape_configs:
- job_name: "springboot"
  metrics_path: "/actuator/prometheus"
  static_configs:
  - targets:
    - "<my_spring_boot_app_ip>:<port>"
- job_name: "prometheus"
  static_configs:
  - targets:
    - "localhost:9090"

 

그라파나

바로 promethus 로 실행해서 모니터링 하기 보기가 어렵다.

version: "3.3" # 파일 규격 버전
services: # 이 항목 밑에 실행하려는 컨테이너 들을 정의
  grafana: # 서비스 명
    image: grafana/grafana    # 사용할 이미지\
    # restart: always
    container_name: grafana # 컨테이너 이름 설정
    ports:
      - "3000:3000" # 접근 포트 설정 (컨테이너 외부:컨테이너 내부)
    environment: # -e 옵션
      GF_SECURITY_ADMIN_PASSWORD: secret
    volumes:
      - /Users/폴더명/docker_voluems/grafana/grafana-storage:/var/lib/grafana

Install and Run

  • 기본 포트: 3000
  • 기본 계정 ID/PW: admin/admin
  • GF_SECURITY_ADMIN_PASSWORD 옵션으로 admin 패스워드 변경 가능

 

반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
telegraf 시작하기  (0) 2022.01.04
Burrow 시작하기  (0) 2021.12.30
ZIPKIN 시작하기  (0) 2021.11.25
반응형

라즈베리 파이를 미니 서버로 사용하기 위해 새로 구매를 했다.

세팅조차 처음이라 포스팅을 한다.

 

목차

1. Micro SD 카드에 라즈비안 이미지 라이팅(writing)

2. SSH 활성화

3. 라즈베리파이 동작

4. SSH 클라이언트 사용하여 라즈베리파이에 접속

 

 

1. Micro SD 카드에 라즈비안 이미지 라이팅(writing)

키트를 샀을때 sd 카드가 왔을거다. sd 카드를 pc 에 연결시켜 라즈비안 os 이미지를 sd카드에 업로드 해야한다.

 

Raspberry Pi OS를 Micro SD 카드에 인스톨하기 위해 사용할 프로그램을 다운로드하여 설치해야한다.

윈도우, 맥, 리눅스 용을 다운로드 받을 수 있다.

https://www.raspberrypi.org/software/ 

 

라즈베리파이를 위한 운영체제를 선택하면 다운로드하여 Micro SD카드에 기록까지 해주는 프로그램이다. 

CHOOSE OS 를 선택 한 후 Raspberry Pi OS(32-bit) 를 선택한다. 

 

그 후 CHOOSE SD CARD 를 클릭하고 Micro SD카드를 선택한다.

다 되면 WRITE 를 선택한다.

설치가 조금 걸린다.

 

 

2. SSH 활성화

2016년 이후로 라즈비안은 보안상의 이유로 디폴트로 SSH 가 비활성화 되어 있다고 한다.

PC 에서 활성화 시키는 방법은 연결 후 os 업로드가 완료 되었다면, 

boot 드라이브를 들어가 ssh 파일을 만들면 끝이다.

ssh 파일 내용은 없어도 된다.

그냥 ssh 라는 이름의 파일을 만들자.

 

ssh 파일이 생성되면 라즈베리파이로 ssh 접속이 활성화가 된다.

 

3. 라즈베리 파이 사용하기

라즈베리 파이 OS 를 업로드 한 SD 카드를 끼운다.

c타입의 전선을 power 포트에 끼운다.

랜선을 Network 포트에 끼운다.

 

다음과 같이 진행하고, 라즈베리파이에 연결된 ip 주소를 확인한다.

나같은 경우는 iptime 에 연결해서 iptime 에 할당된 ip 주소에 raspberry 가 떠서 확인했다.

ip주소를 확인 할 수 있는 ip 대역을 이용해라.

 

4. 라즈베리파이 접속하기

ip 가 192.168.0.1 기본게이트 내에서 192.168.0.30 으로 확인되었다.(22 port)

putty 나 각자 ssh 접속 툴을 사용해서 접속하자.

기본계정은 pi 

비밀번호는 raspberry 이다.

 

 

반응형
반응형

docker compose 란

 

도커 컴포즈는 컨테이너 여럿을 띄우는 도커 애플리케이션을 정의하고 실행하는 도구(Tool for defining and running multi-container Docker applications) 이다.

컨테이너 실행에 필요한 옵션을 docker-compose.yml이라는 파일에 적어둘 수 있고, 컨테이너 간 의존성도 관리할 수 있어서 좋다.

 

도커와 도커 컴포즈를 비교하면 다음과 같다.

  • Dockerfile vs. Dockerfile-dev: 서버 구성을 문서화한 것(=클래스 선언이 들어 있는 파일)
  • docker build vs. docker-compose build: 도커 이미지 만들기(=클래스 선언을 애플리케이션에 로드)
  • docker run의 옵션들 vs. docker-compose.yml: 이미지에 붙이는 장식들(=인스턴스의 변수들)
  • docker run vs. docker-compose up: 장식 붙은 이미지를 실제로 실행(=인스턴스 생성)

간단히 말해 docker run 으로 실행하면 매번 복잡한 옵션 및 명령어들을 여러개 적어두고 실행해야 하는데, 

docker-compose 는 docker-compose.yml 에 사용하고자 하는 도커이미지 및 옵션 값들을 작성해 놓고 docker-compse up 이라는 명령어로 일관적으로 실행할 수 있다.

하나씩 실행해야 하는 수고로움이 덜어진다.

 

설치

docker-compose version 을 치고 조회가 되면 설치할 필요가 없다.

 

없다면 설치하면 된다.

docker-compose 설치는 매우매우 쉽다. 아래를 따라하면 된다.

출처는 https://docs.docker.com/compose/install/

윈도우는

curl -L https://github.com/docker/compose/releases/download/1.6.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

chmod +x /usr/local/bin/docker-compose

docker-compose --version

 

docker-compose 속성

version

version: '2.1'

docker run에서는 없었던 부분입니다. docker-compose.yml 파일의 제일 윗부분에는 파일 규격 버전을 적는다. 파일의 규격에 따라 지원하는 옵션이 달라지며, 최근에 "3.1"이 등장하긴 했지만 보통은 "2"나 "2.1"을 사용해도 충분.

services

services:

이 항목 밑에 실행하려는 서비스들을 정의한다. 서비스란, 앱 컨테이너나 postgres 컨테이너 각각의 묶음이다.

services 하위

서비스의 이름

image

image: postgres:9.6.1

db 서비스에서 사용할 도커 이미지를 적는다.

volumes

volumes: - ./docker/data:/var/lib/postgresql/data

docker run으로 앱 컨테이너를 실행할 때 --volume 옵션을 사용하여 데이터베이스의 데이터를 로컬 컴퓨터에 저장했던 부분과 같다.

다만 docker-compose.yml의 volumes에는 상대 경로를 지정할 수 있다는 점이 다르다.

environment

environment: - POSTGRES_DB=sampledb - POSTGRES_USER=sampleuser - POSTGRES_PASSWORD=samplesecret - POSTGRES_INITDB_ARGS=--encoding=UTF-8

docker run에서 -e 옵션에 적는 내용이다. 마지막의 POSTGRES_INITDB_ARGS 부분이 추가되었는데, 데이터베이스 서버의 인코딩을 설정하기 위함이다.

healthcheck

healthcheck: test: "pg_isready -h localhost -p 5432 -q -U postgres" interval: 3s timeout: 1s retries: 10

postgres 서비스가 제대로 실행될 뿐만 아니라 데이터베이스에 접근할 수 있는지도 파악을 해야 합니다.

healthcheck는 바로 이것을 제어할 수 있습니다. 검사에 사용할 명령(test)을 3초 간격(interval)으로 열 번 시도(retries)하며, 각 시도에서 타임아웃은 1초(timeout)로 지정하였다.

여기서 사용한 pg_isready 명령은 데이터베이스 서버에 접근할 수 있는지를 파악. 

 

service 하위

앱 서비스의 이름으로 지정자 마음대로 지으면 된다.

 

build

build: context: . dockerfile: ./compose/django/Dockerfile-dev

db 서비스와 달리 앱 서비스는 도커 이미지를 빌드할 일이 잦기 때문에, 특정 이미지 대신 build 옵션을 추가한다.

context는 docker build 명령을 실행할 디렉터리 경로라고 보면 된다.

dockerfile은 도커 이미지를 빌드하는 데 사용할 Dockerfile을 지정하면 된다. 

environment

environment: - DJANGO_DEBUG=True - DJANGO_DB_HOST=db - DJANGO_DB_PORT=5432 - DJANGO_DB_NAME=sampledb - DJANGO_DB_USERNAME=sampleuser - DJANGO_DB_PASSWORD=samplesecret

환경 변수는 그냥 docker run을 할 때보다 좀더 자세하게 적었습니다. 각 값은 Django 설정 파일(djangosample/settings.py)에서 사용합니다.

ports

ports: - "8000:8000"

도커 컴포즈로 서비스를 실행하면 기본적으로 가상의 네트워크가 하나 만들어지고, 네트워크 외부의 접근이 막힙니다. (도커 컨테이너가 그렇듯이요.) 따라서 외부에서 접근할 수 있는 포트를 지정해주어야 한다. 여기서는 Django 개발 서버의 기본 포트는 8000을 지정하였습니다.

depends_on

depends_on: db: condition: service_healthy

서비스가 하나 이상일 때, 실행 의존성을 지정할 수 있다. 여기서 지정한 내용은, db 서비스가 실행된 후에 django 서비스를 실행하겠다는 의미. contidion 뒤에는 서비스 시작(service_started)이나 서비스 헬스체크 성공(service_healthy)을 지정할 수 있다.

db 서비스의 healthcheck 부분과 여기서의 service_healthy 부분이 서로 맞물리면, db 서비스에서 데이터베이스 서버 접속이 가능해진 순간 이후에야, django 서비스가 시작한다.

depend_on에서 condition을 지정하는 방식이 도커 컴포즈 파일 규격 3.0과 3.1에서는 제대로 작동하지 않는다고 합니다.

links

links: - db

docker run에서 --link 옵션에서 지정했던 내용입니다. 앱 컨테이너 안에서 db 서비스를 db라는 이름으로 참조할 수 있다.

command

command: /start-dev.sh

docker run으로 앱 컨테이너를 실행할 때 가장 마지막에 적었던 ./manage.py runserver 0:8000을 대신할 셀 스크립트 파일을 하나 만들었습니다. 다음은 start-dev.sh의 내용이다.

#!/bin/sh python manage.py migrate python manage.py runserver 0:8000

volumes

volumes: - ./:/app/

docker run으로 앱 컨테이너를 실행할 때 프로젝트 루트 디렉터리를 컨테이너 안에 연결했던 부분과 같습니다.

 

예시

version: "3.3" # 파일 규격 버전
services: # 이 항목 밑에 실행하려는 컨테이너 들을 정의
  db: # 서비스 명
    image: mysql:5.7 # 사용할 이미지\
    # restart: always
    container_name: jun-mysql # 컨테이너 이름 설정
    ports:
      - "3306:3306" # 접근 포트 설정 (컨테이너 외부:컨테이너 내부)
    environment: # -e 옵션
      MYSQL_ROOT_PASSWORD: '비번'  # MYSQL 패스워드 설정 옵션
      MYSQL_USER: '계정'
      MYSQL_PASSWORD: '비번'
    volumes:
      - /Users/유저명/폴더명:/var/lib/mysql  
    # command: # 명령어 실행
      # - mysqld --default-authentication-plugin=mysql_native_password
      # - --character-set-server=utf8mb4
      # - --collation-server=utf8mb4_unicode_ci
  mongo:
    image: mongo
    # restart: always
    ports:
      - 9017:27017
    environment:
      MONGO_INITDB_ROOT_USERNAME: 유저계정
      MONGO_INITDB_ROOT_PASSWORD: 비번  

예시2

version: '2.1'

# 변경 부분!
volumes:
  django_sample_db_dev: {}

services:
  db:
    image: postgres:9.6.1
    volumes:
      # 여기도 변경 부분!
      - django_sample_db_dev:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=sampledb
      - POSTGRES_USER=sampleuser
      - POSTGRES_PASSWORD=samplesecret
      - POSTGRES_INITDB_ARGS=--encoding=UTF-8
    healthcheck:
      test: "pg_isready -h localhost -p 5432 -U postgres"
      interval: 3s
      timeout: 1s
      retries: 10

  django:
    build:
      context: .
      dockerfile: ./compose/django/Dockerfile-dev
    environment:
      - DJANGO_DEBUG=True
      - DJANGO_DB_HOST=db
      - DJANGO_DB_PORT=5432
      - DJANGO_DB_NAME=sampledb
      - DJANGO_DB_USERNAME=sampleuser
      - DJANGO_DB_PASSWORD=samplesecret
      - DJANGO_SECRET_KEY=dev_secret_key
    ports:
      - "8000:8000"
    depends_on:
      db:
        condition: service_healthy
    links:
      - db
    command: /start-dev.sh
    volumes:
      # 마지막으로 여기도!
      - ./manage.py:/app/manage.py
      - ./requirements.txt:/app/requirements.txt
      - ./requirements-dev.txt:/app/requirements-dev.txt
      - ./djangosample:/app/djangosample

docker-compose 실행하기

https://docs.docker.com/compose/wordpress/

에 워드프레스 docker-compose.yml 파일이랑 실행방법 있음

 

yml 파일 설치된 dir 에서 실행

docker-compose up -d ##시작
docker-compose down -d ##내리기

 

 

참고문헌

> http://raccoonyy.github.io/docker-usages-for-dev-environment-setup/ --도커 docs

> docs.microsoft.com/ko-kr/visualstudio/docker/tutorials/use-docker-compose - ms에서 만든 문서 - build 도 나옴

반응형
반응형

Mac에서 Alias 설정하는 방법

 

터미널 열고

$ vi ~/.bash_profile

bash_profile 파일을 열고 

원하는 alias 를 적용한다.

 

아래처럼 alias = "명령어"

 로 설정하면 된다.

# Source bashrc
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

alias cl='clear'

 

파일 저장 후 

$ source ~/.bash_profile

를 ㅈ거용하면 alias 가 적용된다.

반응형
반응형

 

hostname

hostname -I

실행 후

아래와 같이 현재 주소 IP 가 나타남

222.111.789.000

 

ip addr show 사용하기

ip addr show

를 치면 많은 주소가 나오는데 이 중 inet 뒤에 있는 ip 주소가 해당 서버의 ip 주소이다.

출력되는 정보가 많다면

ip addr | grep "inet"

으로 inet 문구가 포함된 라인만 출력 할 수 있고,

ip -4 addr

여기서는 ipv4 에 해당하는 내용만 가져올 수 있다.

 

 

 

ifconfig

ifconfig

윈도우의 ipconfig 와 비슷하다.

inet 뒤의 ip 주소가 서버 ip 이다.

 

여기서도 grep 으로 원하는 inet 부분만 찾자

ifconfig | grep "inet"
반응형
반응형

CPU Usage

CPU 사용량은 시스템 사용률과 사용자 사용률 등을 합친값이다.

시스템 사용률은 운영체제가 사용한 CPU 사용률을 의미하며 사용자 사용률은 응용프로그램이 사용하는 CPU 사용률을 의미한다.

 

System 사용률이 높다면 시스템 사양을 높여야 한다.

USer 사용률이 높다면 시스템 업그레이드 또는 애플리케이션의 분배를 고려해야 한다.

 

CPU Idle

CPU Idle 은 CPU 가 모든 일을 끝내고 쉬는 시간을 의미한다. 일반적으로 CPU Usage 가 높다면 CPU Idle 은 낮을 것이다. 

하지만 I/O Wait 또는 Steal 등의 값으로 인해 이 비율이 항상 일정치 않다.

 

Idle 값이 항상 낮다면 시스템을 업그레이드 해야한다.

 

CPU I/O Wait

CPU가 입출력을 대기하는데 사용한 시간의 비율을 보여준다. 프로세스에 바로 접근 할 수 없는 상황인 경우 I/O Wait 비율은 늘어난다.

iowait 은 cpu 본연의 job이 아닌 다른 장치와의 통신 때문에 cpu job이 일시적으로 waiting 된 상태를 말한다. 예를 들어서 cpu와 hdd간의 테이터 통신이 많다면 (hard disk에 writing 부하가 심하게 올라간다면) iowait이 높아지게 된다.

 

I/O Wait 값이 높다면 하드 디스크를 SSD로 교체하거나 Raid 유형을 바꿔야 한다.

 

CPU Steal %

다른 OS 에 의해서 빼앗긴 CPU 시간의 비율, 가상화되어 있지 않다면 Steal 값은 사용되지 않으므로 항상 0으로 표시된다.

가상머신이 많아지는 경우, 동일한 물리 장비에서 제공되는 환경이다보니,

특정 가상머신이 CPU를 많이 차지하게 되면, 다른 머신들도 따라서 느려지게 되는데,

이 현상을 CPU Steal이라고 한다.

 

 

CPU Load(부하)

CPU Load 는 CPU 에 실행중이거나 대기중인 작업(프로세스) 의 개수를 평균으로 보여주는 값이다.

CPU에 실행중이거나 대기중인 작업이 있는지 100번 확인할 때 2개의 작업이 있다면 CPU 로드는 0.02 이다.

CPU 가 항상 실행중이고 대기중인 작업없이 효율적으로 정확히 일한다면 CPU Load 는 1이다. 코어가 2개라면 대기중인 작업이 없는 상태일 떄 CPU Load 는 2가 된다.

코어가 4개면 4 이다.

부하가 클 수록 CPU Load 의 값이 커지게 된다. CPU Load 는 남아있는 작업까지 표시해 주는 지표이다.

 

코어가 하나인 경우 CPU Load 의 임계값은 0.7 정로도 둔다. 적당한 평균치

CPU Load 가 지속적으로 0.7 을 넘어간다면 시스템업그레이드를 고려해야 한다.

 

참고문헌

brunch.co.kr/@leedongins/75?fbclid=IwAR3Vm-UPfMb3AFqhymelLPphePD8qtZl_wK57_K89YeOuomCeQ0pZZQC2jM [CPU 지표 정리]

 

반응형

+ Recent posts