반응형

※ 레거시 프로젝트를 운영하다가 정리하게 되었다.

1. pom.xml 에 Nexus 관련 설정을 추가한다

<distributionManagement>
	<repository>
		<id>nexus-releases</id>
		<url>http://${NEXUS-HOST}/nexus/content/repositories/releases/</url>
	</repository>

	<snapshotRepository>
		<id>nexus-snapshots</id>
		<url>http://${NEXUS-HOST}/nexus/content/repositories/snapshots/</url>
	</snapshotRepository>
</distributionManagement>

 

  • 여기서 id를 주목해야한다. 3번의 setting.xml 의 id와 동일해야한다.
  • 또한 대표저장소의 id 나 name 속성과 관련이없다.

 

2. pom.xml 에 Plugin 을 추가한다.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-deploy-plugin</artifactId>
<!--				<version>${maven-deploy-plugin.version}</version>-->
	<configuration>
		<skip>true</skip>
	</configuration>
</plugin>

<plugin>
	<groupId>org.sonatype.plugins</groupId>
	<artifactId>nexus-staging-maven-plugin</artifactId>
	<version>1.5.1</version>
	<executions>
		<execution>
			<id>default-deploy</id>
			<phase>deploy</phase>
			<goals>
				<goal>deploy</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<serverId>nexus</serverId>
		<nexusUrl>http://${NEXUS-HOST}/nexus/</nexusUrl>
		<skipStaging>true</skipStaging>
	</configuration>
</plugin>

 

3. settings.xml 에 서버설정을 추가한다.

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
	  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
<!--	<localRepository/>-->
<!--	<interactiveMode/>-->
<!--	<offline/>-->
<!--	<pluginGroups/>-->
	<servers>
		<server>
			<id>nexus-releases</id>
			<username>${id}</username>
			<password>${password}</password>
		</server>
		<server>
			<id>nexus-snapshots</id>
			<username>${id}</username>
			<password>${password}</password>
		</server>
	</servers>
<!--	<mirrors/>-->
<!--	<proxies/>-->
<!--	<profiles/>-->
<!--	<activeProfiles/>-->
</settings>

※ settings.xml 참고 링크 - maven.apache.org/settings.html#Quick_Overview

  • 위에도 언급했지만 id를 주목해야한다. pom.xml 에 설정한 id값과 동일해야한다.
  • 또한 대표저장소의 id 나 name 속성과 관련이없다.

 

4. mvn 명령어를 통해 빌드 결과물을 넥서스에 배포한다.

옵션을 주지않으면 테스트가 실행이 될텐데 아래의 옵션을 통해 스킵할 수 있다.
mvn clean deploy
mvn clean deploy -Dmaven.test.skip=true

 

※ deploy 명령어 참고 링크 - maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html

 

Maven – Guide to deploying 3rd party JARs to remote repository

Guide to deploying 3rd party JARs to remote repository Same concept of the install:install-file goal of the maven-install-plugin where the 3rd party JAR is installed in the local repository. But this time instead to local repository the JAR will be install

maven.apache.org

배포 작업의 경우에는 이 작업이 배포 파이프라인의 마지막 작업이어야 하므로 테스트를 건너뛰어도 좋습니다.  이러한 배포 파이프라인의 일반적인 예로는 Jenkins 작업의 연속이 있으며, 각 작업은 성공적으로 완료될 경우에만 다음 작업을 트리거합니다. 따라서 배포 작업이 실행될 때까지 프로젝트의 모든 테스트 제품군을 실행하는 것은 파이프라인의 이전 작업의 책임입니다. 모든 테스트는 이미 통과해야 합니다.

 

5. 결론

Maven 아티팩트를 Nexus로 배포하기 위한 간단하면서도 매우 효과적인 솔루션입니다. 또한 기본 maven-deploy-plugin 대신 nexus-staging-maven-plugin이 사용되고 스테이징 기능이 비활성화되는 등 어느 정도 의견이 분분합니다. 이러한 선택으로 솔루션을 간단하고 실용적으로 만들 수 있습니다.

 

참고자료) www.baeldung.com/maven-deploy-nexus

 

Maven Deploy to Nexus | Baeldung

Maven Deploy to Nexus - The Nexus Snapshot Repository in the pom and how to set up the Deployment Process.

www.baeldung.com

#

반응형
반응형

Docker 란?

 기존의 온프레미스 환경에서 서버 구축의 어려움을 Docker-Engine 위에서 Docker-Registry를 통해 Docker-Images을 Docker-Compose로 쉽게 구성 맟 관리할 수 있게 구축을 해 주는 기술입니다.

 

Docker-Hub 란?

- GitHub 이나 Bitbucket과 같은 소스코드 관리 툴과 연계하여 코드를 빌드하는 기능이나 실행 가능한 애플리케이션의 이미지를관리하는 기능을 갖춘 Docker의 공식 리포지토리 서비스 입니다.

 

Tag

- 도커 이미지에 대한 버전이라고 보면 됩니다. (ngnix:latest, debian:7)

 

 

1. 도커 시스템 정보

  • docker version
  • docker -v
  • docker system info
  • docker system df
  • docker system df -v

 

2. 컨테이너 명령어

docker container run 명령은 도커 이미지로부터 컨테이너를 생성하고 실행하는 멸령이다.

도커 컨테이너는 이미지를 바탕으로 작성된다.

 

docker container run <image> <command>

docker container run ubuntu:latest /bin/echo 'Hello Wolrd'

 

docker container run --name webserver -d -p 80:80 ngnix

docker container run --name webserver -d -p 80:80 ngnix:latest

- webserver 라는 이름의 컨테이너로 nginx 이미지를 띄운다.

-  [-d] 옵션은 detach로 백그라운드에서 실행을 의미한다.

-  [-p] 옵션은 포트 포워딩이다.

 

docker container run -it --name "test1" centos /bin/cal February 2018

- 컨테이너를 생성/실행하면서 콘솔에 결과를 출력하고 이름은 "test1"로 centos이미지를 올리고 /bin/cal 명령어를 실행한다.

docker container run -it --name "test2" centos /bin/bash

- [-i] 옵션은 컨테이너를 실행할 때 컨테이너 쪽 표준 입력과의 연결을 그대로 유지한다. 그러므로 컨테이너 쪽 셀에 들어가서 명령을 실행할 수 있다.

- [-t] 옵션은 유사터미널 기능을 활성화하는 옵션인데, -i 옵션을 사용하지 않으면 유사 터미널을 실행해도 여기에 입력할 수가 없으므로 -i와 -t 옵션을 합쳐 축약한 -it 옵션을 사용한다.

 

컨테이너 상태 확인

docker container ls [option]

- [--all|-a] :모든 컨테이너

docker container ps

docker container stats <container-name>

docker container top <container-name>

 

컨테이너 연결

docker container attach <container-name>

- ctrl-c : 컨테이너 종료

- ctrl-

 

 

컨테이너 종료/시작/재시작/삭제

  • docker stop <container-name>
  • docker start <container-name>
  • docker container restart <container-name>
  • docker container rm <container-name>
  • docker container rm -f <container-name>
    • - 강제 종료 및 삭제

 

docker container run --cpu-shares=512 --memory=1g centos

- [--cpu-shares] : CPU의 사용 배분(비율)

- [--memory] : 사용할 메모리를 제한하여 실행

- [--evn=<환경변수>] : --env JAVA=xxx, -e JAVA=xxx

- [--user=사용자명] : --use

 

docker container exec -it <container> /bin/echo "HelloWorld"

docker container port <container>

docker container rename

docker container cp

 

컨테이너 로그 - 표준 출력 연결하기

docker container logs [options] <container-id | container-name>

- docker container logs -f $(docker container ls --filter "ancestor=mysql" -q )

 

컨테이너와 호스트의 데이터 볼륨(컨테이너의 데이터퍼시스턴스 기법)

-v 옵션을 사용하여 호스트와 컨테이너 사이의 데이터를 공유한다.

docker container run -v 호스트디렉토리:컨테이너디렉토리 repository[:tag] [command]

호스트-컨테이너 데이터볼륨은 호스트 쪽 특정 디렉터리에 의존성을 갖는다. 데이터 볼륨 컨테이너의 볼륨은 도커에서 관리하는 영역인 호스트 머신의 /var/lib/docker/volumes/ 아래에 위치한다. 데이터볼륨 컨테이너 방식은 도커가 관리하는 디렉터리 영역에만 영향을 미친다.

 

 

3. 이미지 명령어

docker image pull [option] <image-name>[:tag]

 

docker image pull - a centos 

- centos의 모든 이미지 다운로드

docker pull nginx (이미지 다운로드)

 

docker image ls [option] [repository]

docker image ls

docker images

 

docker image inspect nginx:latest

- 도커 임지 상세 정보 표시

docker image inspect --format="{{ .ContainerConfig.Image}}" nginx:latest

- 이미지값만 표시

 

docker image tag <origin-image-name> <new-image-name:tag>

- 이미지 tag 를 사용해 새이름으로 이미지를 복사한다.

docker image tag nginx:latest starlord/webserver:1.0

 

docker search  [option] <keyword>

- 도커 허브에 공개되어 있는 이미지들을 조회한다.

docker serach ngnix

 

docker image rm <optino> <image-name>

- 도커 이미지를 삭제한다.

 

docker image prune [-a|-f]

- 사용하지 않는 이미지들을 삭제한다.

 

컨테이너로부터 이미지 작성 및 확인

  • docker container commit [option] <container-name> <image-name:tag>
  • docker container commit -a "starlord" webserver ws-image:1.0
  • docker image ls
  • docker image inspect ws-image:1.0

 

컨테이너로부터 tar 파일 생성

  • docker container export <container>
  • docker container export <container> > current.tar
  • ls -al
  • tar -tf current.tar
  • tar tf current.tar | more

 

이미지를 tar 로 저장하기

  • docker image save [option] <save-file> [image-name]
  • docker image save -o save.tar webserver
  • docker image load [option] <image>

 

tar로부터 이미지를 읽어들이기

  • docker imae load [option] <image-name>

 

 

4. 네트워크 명령어

  • docker network create -d bridge webap-net
  • docker container run --net=webap-net -it centos
  • docker network ls --no-trunc
  • docker network connect [option] <network-name> <container-name>
  • docker network disconnect <network-name> <container-name>
  • docker network inspect [opeion] network
  • docker network rm <network-name>

 

 

5.  불필요한 이미지/컨테이너를 일괄삭제

docker system prune [option]

- [-a | -f] 

 

 

6. Dockerfile로부터 이미지 만들기

도커 파일을 생성한다

  • touch Dockerfile 

도커 파일을 빌드한다

  • docker build -t <image-name> <경로[절대|상대]>
  • docker build -t sample:1.0 ./
  • docker build -t sample:1.0 -f <filename> ./
  • docker build -t sample1 -f Dockerfile.layer1 ./
  • docker images 

 

Dockerfile example

 

# step1. ubuntu

FROM ubuntu:latest

#step2. ngnix

RUN apt-get update && apt-get install -y -q nginx

#step3. file copy

COPY index.html /usr/share/nginx/html/

#step4. start nginx

CMD ["nginx", "-g", "daemon off;"]

 

도커파일의 명령 목록

- FROM 베이스 이미지 지정

- RUN 명령 실행 : shell형식, exec형식 (이미지를 작성하기 위해 실행하는 명령)

- CMD컨테이너 실행 명령 (Dockerfile 안에서는 하나의 명령만 가능, 우선적인 명령이 있을 시 덮어짐)

- LABEL 라벨 설정

- EXPOSE 포트 익스포트

- ENV 환경변수

- ADD 파일/디렉토리 추가 (ADD <호스트파일경로> <Docker 이미지의 파일 경로>)

- COPY 파일 복사 (COPY <호스트파일경로> <Docker 이미지의 파일 경로>)

- ENTRYPOINT 컨테이너 실행 명령 (다른 명령이 있어도 같이 쓰임)

- VOLUME 볼륨마운트

- USER 사용자 지정

- WORKDIR 작업 디렉토리

- ARG Dcokerfile 안의 변수

- ONBUILD 빌드 완료 후 실행되는 명령

- STOPSIGNAL 시스템 콜 시그널 설정

- HEALTHCHECK 컨테이너의 헬스 체크

-  SHELL 기본 쉘 설정

 

 

7. Docker Compose

여러 컨테이너를 모아서 관리하기 위한 툴입니다.

docker-compose.yml 을 생성 후 docker-compose up 명령어를 수행하면 됩니다.

크게 services: , networks: , volumes: 를 정의합니다.

 

docker-compose up

docker-compose up -d

- 컨테이너를 백그라운드로 시작 

docker-compose up --build

docker-compose config

docker-compse -v or -version

 

도커 컴포즈 서브 명령

up, ps, logs, run, star, stop, restart, pause, unpause, port, config, kill, rm, down

 

ex) docker-compose.yml

 

이미지지정

container_name: 'this-is-container'

labels:

    - "com.xxxx=yyyyy"

labels:

    com.xxxx: "yyyyy"

version: '1.0'

services: 

webserver:

    image: <image-name:tag>

 

빌드지정

services:

    webserver:

          build: . 

 

services:

    webserver:

          build:

              context: /directory

              dockerfile: filename

              args:

                   key1: value1

                   key2: value2

 

services:

    webserver:

          build: .

          depends_on:

              - db

              - redis

    redis:

          image: redis

    db:

          image: postgres

 

environment:

    - KEY1: value1

    - KEY2: value2

env-file: envfile

 

docker-compose ps 명령어로 확인 할 수 있습니다.

docker-compose stop 명령어로 컨테이너들을 종료할 수 있습니다.

docker-compose down 명령어를 사용하면 리소스들을 삭제할 수 있습니다.

docker-compose down --rmi all 모든 이미지, 네트워크, 볼륨 다 삭제

 

 

8. Docker Machine

Docker-Machine 은 호스트 머신/클라우드/가상 환경 등에  Docker의 실행 환경을 만들 수 있는 커맨드라인 툴입니다.

 

docker-machine create —driver <driver-name> <Docker-Machine-Name>

docker-machine ls

docker-machine rm <docker-machine>

docker-machine ssh <docker-machine>

docker-machine status <docker-machine>

docker-machine scp <docker-machine>:/directory

  • 실행환경으로부터 파일 다운로드 

docker-machine ip <docker-machine>

docker-machine inspect <docker-machine>

 

클라우드를 사용하여 Docker 실행환경을 구축할 때는 오케스트레이션을 위한 매니지드 서비스 외에도 소스코드나 Docker 이미지의 리포지토리 및 로깅 등과 같은 여러 서비스를 조합하여 시스템을 구축하게 됩니다.

 온프레미스 환경에서는 네트워크 부설/ 서버 기기의 도입/ OS의 설정 등 물리적인 작업 및 어느 정도의 초기 비용이 필요하기 때문에 시스템의 요건에 따라 사전에 상세한 설계가 필요합니다. 하지만 클라우드를 사용한 경우는 서비스의 조합만으로 재빨리 시스템을 구축할 수 있는 것이 큰 특징입니다.

 한편 클라우드만의 설계 포인트도 있습니다. 예를 들어 클라우드 서비스를 어떻게 조합하는 것이 최적인지, 영구 데이터의 특성에 맞춰 어떤 스토리지 서비스를 골라야 좋을지 등입니다. 이러한 클라우드의 특성을 고려하여 장점을 최대한 살리는 형태로 구축된 아키텍처를 클라우드 네이티브 아키텍처라고 합니다.

 

docker pull registry-name/resource-name:latest

docker container run -d -p 8080:8080 --name resource-name registry-name:latest

docker exec <containerid> java -version

 

컨테이너 쉘 접속

  • docker ps -a
  • docker exec -it <container-name or id> /bin/bash

 

#

반응형
반응형

1. 레디스 접속

redis-cli 명령어로 접속한다.

 

2. 레디스 설정 확인

config get * 명령어로 모든 설정값을 확인할 수 있다.

 

3. 레디스 정보 확인

info 명령어로 서버에 대한 통계?데이터들을 확인할 수 있다.

 

4.  레디스 DB 선택 

select <index> 

ex) select 10  : 10번 DB를 선택

 

5. 키에 대한 타입 조회

type <key>

ex) type mytestkey:1

레디스는 키에 대한 타입 별로 조회할 수 있는 명령어들이 별도로 있다.

 

6. 조회 - 타입에 따라 다름

GET <KEY>

 

list 조회

LRANGE <KEY> <START> <END>

ex) LRANGE mytestkey:1 0 -1

 

zset 조회

ZLRANGE <KEY> <START> <END>

ex) ZLRANGE mytestkey:1 0 -1

 

7. 계산 - 타입에 따라 다름 

zcard <key> 

 

 

레디스 참고 기사

http://m.zdnet.co.kr/news_view.asp?article_id=20131119174125&re=zdk#imadnews

 

 

반응형
반응형

Redis 기초

Redis의 주요 특징

Redis(Remote Dictionary Server) 는 오픈소스 NoSql로서 key-value 타입의 저장소로 주요 특징은 다음과 같습니다.

  • 영속성을 지원하는 인메모리 데이터 저장소다.
  • 읽기 성능 증대를 위한 서버 측 복제를 지원한다.
  • 쓰기 성능 증대를 위한 클라이언트 측 샤딩을 지원한다.
  • ANSI C로 작성됐다. 따라서 ANSI C 컴파일러가 동작하는 곳이면 어디든 설치 및 실행이 가능하다.
  • 레디스 클라이언트는 대부분의 언어로 포팅되어 있다.
  • 전세계 많은 서비스에서 사용되고 있으며 성능적으로 검증된 솔루션이다.
  • 문자열, 리스트, 해시, 셋, 정렬된 셋과 같은 다양한 데이터형을 지원한다. 메모리 저장소임에도 불구하고 많은 데이터형을 지원하므로 다양한 기능을 구현할 수 있다.

레디스와 멤캐시드의 차이

멤캐시드

본질적으로 고성능 분산 메모리 객체 캐싱 시스템이지만, 원래는 동적 웹 서비스의 DB부하를 경감시키는 것이 목적이었다.

레디스

오픈소스이며 향상된 key-value 저장소다. 값으로 문자열, 리스트, 해시, 셋, 정렬된 셋을 포함할 수 있기 때문에 종종 데이터 구조 서버로 지칭된다.

레디스 키와 데이터타입

레디스의 키와 값의 관계

레디스에 키와 값을 저장하면 레디스 내부에서는 키를 위한 메모리 영역과 값을 위한 메모리 영역이 생성되는데, 키를 위한 메모리 영역에는 값이 저장된 메모리 영역의 포인터가 저장된다. 같은 키로 다른 데이터를 저장하는 명령이 입력되면 값을 저장하기 위한 새로운 메모리 영역이 생성되고 키에 저장된 포인터 정보가 새로운 값의 메모리 영역을 가리키게 되며, 이전에 저장되었던 값의 메모리는 사라지게 된다.

expireat, expire, ttl, persist(만료시간제거)

키의 만료 처리

저장된 키에 대하여 만료시간을 설정할 수 있다(레디스가 멤캐시드와 같은 캐시 시스템과 비교되는 이유가 바로 이 기능 때문이다).  레디스가 제공하는 만료 처리 방법은 '지정된 시간에 만료'와 (expireat) '명령이 수행된 이후부터 일장 시간 이후의 만료' (expire)를 지원한다.

대량의 데이터 입력

-   레디스 클라이언트 라이브러리를 사용해서 하나씩 순차적으로 데이터를 입력하는 방법
-   레디스 파이프라인을 사용하여 한꺼번에 입력하는 방법
    cat redis\_data\_command.txt | ./redis\_cli --pipecat redis\_data\_protocol.txt | ./redis\_cli --pipelettuce 나 jedis 의 파이프라인 라이브러리
-   레디스 스냅샷 파일에 직접 기록하는 방법

레디스가 지원하는 데이터 인코딩

  • raw : 입력된 데이터를 변환하지 않고 그대로 저장하는 상태다.
  • integer : 입력된 숫자 형식의 데이터를 숫자 데이터 타입으로 저장하고 있는 상태다. 주로 incr, incrby 명령으로 저장되는 데이터가 integer 인코딩을 사용한다.
  • hashtable : raw 인코딩을 가진 데이터를 저장하고 이쓴 해시 테이블을 의미한다. 레디스의 기본 인코딩중의 하나로 전혀 압축되지 않는다.
  • zipmap : 압축된 형태의 map 구조를 표현하는 데이터 인코딩이다. 레디스 2.6미만 버전까지만 사용되고 2.6 버전부터는 ziplist로 통합된다.
  • linkedlist : raw 인코딩을 가진 데이터를 저장하고 있는 연결 리스트를 의미한다. 레디스의 기본 인코딩 중의 하나로 전혀 압축되지 않는다.
  • ziplist : 압축된 형태의 데이터 인코딩이다. 해시, 셋, 정렬된 셋 데이터형이 압축된 형태의 인코딩을 의미한다.
  • intset : 입력된 숫자 형식의 데이터를 숫자 데이터 타입으로 변환하여 셋 데이터에 저장된 상태다.
  • skiplist : raw 인코딩을 가진 데이터를 저장하고 있는 정렬된 셋 데이터의 인코딩을 의미한다.

해시데이터

해시 데이터는 문자열 필드와 값으로 이루어진 Map구조로 되어 있다. 해시 데이터에는 2의 32승 -1 개의 필드와 값을 저장할 수 있는데,
숫자로 바꾸면 약 42억개가 넘는다. 또한 hgetall, hkeys, hvals를 제외한 모든 해시 명령의 시간복잡도는 O(1)이다. 해시 데이터는
키 하나가 여러 개의 필드-값 쌍으로 이루어진다. 이런 구조는 일반적인 프로그래밍 언어의 맵 자료구조와 동일하다.

해시 데이터의 키 목록 조회

모든 키의 목록과 모든 값의 목록을 조회할 때는 hgetall을 사용하면 된다. 키의 목록이나 값의 목록만을 조회하는 명령은 hkeys, hvals 이다.
hkeys 명령은 주어진 키에 저장된 모든 필드의 목록을 조회한다. hvals는 주어진 키에 저장된 모든 값에서 필드 이름을 제외한 값의 목록을 조회한다.

해시 데이터의 특별한 유형 zipmap

 레디스의 해시 데이터는 해시 데이터에 저장된 필드 수가 수백 개 정도일 때 매우 적은 양의 메모리에 많은 데이터를 저장할 수 있다.
이는 레디스가 메모리를 효율적으로 사용하기 위하여 내부적으로 몇 가지 특별한 저장구조를 사용하기 때문에 가능하다. 레디스는 데이터
저장에 구조체를 사용하는데, 이 구조체는 실제 데이터가 저장된 위치를 가르키는 포인터와 몇 가지 부가 정보로 구성된다. 원래 데이터에
부가 정보가 덧붙으면 자연스레 더 많은 메모리를 사용하게 되는데, 레디스는 메모리 공간을 절약하기 위해서 세 가지 내부 저장구조
(zipmap, ziplist, intset)를 사용한다. 그런데 이 내부 저장구조를 사용하게 되면 CPU를 더 사용하게 된다. 따라서 CPU와 메모리
공간의 적당한 트레이드 오프를 통해서 가장 효율적인 값을 찾아야 한다. 인스타그램의 개발자가 테스트한 결과, 백만 개의 키와 정수값을
문자열 데이터로 저장하는 데 필요한 메모리는 70MB인데,  zipmap을 사용한 해시 데이터로 저장하면 16MB만 소모된다.
이 zipmap은 레디스 2.6 버전부터 ziplist라는 구조로 대치된다.

Set을 활용한 집합연산

sadd 명령어를 통해 트위터 팔로우/팔로워 구조를 저장하고, sinter 명령어를 통해 두개의 키 사이의 교집합(맞팔)을 구할 수 있다.

유닉스 타임스탬프

 유닉스 타임스탬프는 유닉스에서 사용하는 시간으로서 1970년 1월1일 0시00분00초부터 지금까지 몇 초가 지났는지를 알려주는 값이다.
예를 들어 유닉스 타임스탬프값 '1234567890'은 국제 표준시 2009년 2월13일 31분30초를 나타낸다. 그러므로 'expireat test:key 0'
명령은 국제 표준시 1970년 1월1일 00시00분00초에 키가 만료된다. 한국은 GMT+9를 사용하므로 구해진 유닉스타임스탬프값에 9시간을 더하려고
하는 개발자가 있을지 모르겠다. 레디스는 입력된 타임스탬프값을 GMT값으로 인식하여 처리하므로 별도로 시간을 더할 필요가 없다.

레디스의 성능

레디스는 단일 스레드로 동작하기 때문에 하나의 레디스 인스턴스가 사용할 수 있는 최대 CPU의 개수는 하나다. 따라서 처리 성능을 높이기 위해서 CPU를 추가하는 것은 레디스의 성능 향상에 큰 도움이 되지 못한다. 그래서 스케일아웃처럼 동일한 사양의 시스템을 추가하는 방법을 사용해야한다. 스케일아웃을 하기 위해서 복제(Replication)와 쓰기 분산을 위한 샤딩(sharding)을 사용할 수 있다.

레디스의 복제

복제란 클라이언트가 어느 노드에 접근하더라도 동일한 데이터를 읽을 수 있도록 데이터를 각 노드에 복제하여 저장하는 것을 말한다. 복제를 구성할 때 하나의 마스터에 너무 많은 슬레이브를 구성하지 않도록 한다. 데이터복제를 위한 네트워크 사용률이 데이터 서비스를 위한 네트워크 사용률보다 커지게 되어 매우 느린 응답시간을 보이게 된다. (별도의 네트워크카드 설정)

레디스의 샤딩

메모리 크기와 설정

redis.conf 파일의 maxmemory 설정을 통해 레디스가 사용할 메모리 크기를 설정한다. 이 설정은 물리적인 메모리와 스왑공간을 고려하여 설정해야한다. 스왑공간은 메모리가 적을 경우 메모리의 2배, 메모리가 클 경우 1/2로 한다고 한다. 또한 maxmemory 설정에는 redisObject와 같은 구조체 정보도 모두 포함되니 실제 입력될 데이터의 크기는 설정한 것보다 작게 입력될 것이다.

만약 레디스에 저장될 데이터의 크기를 산정하지 못하여 redis.conf의 maxmemory 설정에 값을 지정할 수 없게 됐다고 가정하자. 그러면 레디스에 데이터가 계속 추가되어 물리 메모리를 모두 사용하게 된다. 이때 운영체제는 애플리케이션이 시스템에서 사용 가능한 물리 메모리보다 더 많은 메모리를 사용하려고 할 때 스왑이라는 가상 메모리 공간을 하드디스크에 생성하여 사용하는데 이 영역을 스왑공간이라 부른다. 이때 스왑영역이 충분하지 않으면 운영체제는 메모리에서 동작 중인 프로세스를 제거하여 사용 가능한 메모리 영역을 확보하게 된다. (OOM - Out Of Memory killer 발생)

여하튼 지정된 레디스의 메모리 크기보다 더 많은 데이터를 저장하려들면 레디스는 오류 메시지를 전송하고 쓰기 요청을 실패한다. 하지만 이 상황에서 읽기 요청은 정상적인 응답시간으로 서비스된다. 그러므로 응답시간이 중요한 서비스에서는 레디스가 사용할 메모리의 크기를 지정하는 것이 유리하다. 레디스에 저장된 데이터의 크기가 maxmemory 설정에 지정된 값을 초과하게 되면 레디스의 쓰기 연산이 실패하게 되고, 이에 레디스는 저장 가능한 메모리 영역을 확보하기 위하여 기존에 저장한 데이터를 지운다. 이와 같은 동작은 redis.conf의 maxmemory-policy 설정에 지정된 값에 따라서 달라지는데 자세한 내용은 아래와 같다.

  • volatile-lru : expire 명령을 사용하여 만료시간이 지정된 키 중에서 만료된 키를 대상으로 최근에 가장 적게 사용된 키를 제거한다.
  • allkey-lru : 모든 키 중에서 최근에 가장 사용이 적은 키를 제거한다.
  • noeviction : 어떤 키도 제거하지 않는다.

maxmemory-sample 설정은 몇 개의 키를 조회하여 삭제할 키를 선정할지 지정한다.

스냅샷이나 AOF를 위해서 호출한 fork 함수는 부모 프로세스와 동일한 크기의 메모리를 사용하는 프로세스를 생성한다. 따라서 부모 프로세스가 사용하는 만큼의 메모리가 남아있지 않으면 fork 함수가 실패하게 된다.
linux /etc/sysctl.conf

vm.overcommit_memory 0, 1, 2 값을 설정할 수 있으며 자세한 설명은 아래와 같다.

  • 0 : 리눅스 시스템의 기본 설정값, 메모리 할당 요청인 malloc 함수의 요청이 들어오면 요청된 크기만큼의 물리적 메모리가 존재할 때에만 메모리를 할당한다.
  • 1 : 메모리 할당 요청인 malloc 함수의 요청이 들어오면 남은 물리 메모리가 없더라도 성공을 응답한다. 단, 요청으로 입력된 크기의 스왑영역이 존재할 때에만 성공한다.
  • 2 : 사용 중인 메모리 크기가 '스왑공간 크기 + vm.overcommit_ratio * 물리 메모리 크기' 이내일 때 메모리를 할당한다.

maxclients

레디스 인스턴스에 접속할 수 있는 클라이언트 수를 지정한다. 실제로는 지정된 값보다 약간 작은 값으로 설정된다. 예를 들어 리눅스에서 실행중인 32비트 레디스의 기본값은 1,024인데, 실제로는 레디스 프로세스가 사용하는 파일디스크립터개수(32개)를 뺀 값이 설정된다. 그리고 운영체제 자체에서 제한이 있을 수 있는데 ulimit 명령어로 확인할 수 있다. "ulimit -n" 을 통해 하나의 프로세스가 처리할 수 있는 최대 파일 디스크립터의 개수를 확인하고, /etc/security/limits.conf 파일에서 수정할 수 있다.

hash-max-ziplist-entries

해시 데이터에 ziplist 인코딩을 사용하여 저장할 데이터 개수를 지정한다. 여기서 지정된 개수보다 많은 데이터가 저장되면 레디스는 자동으로 hashtable 인코딩을 사용하여 저장한다.

hash-max-ziplist-value

해시 데이터에 ziplist 인코딩을 사용하여 저장할 데이터의 크기를 지정한다. 여기서 지정된 크기보다 큰 데이터가 저장되면 레디스는 자동으로 hashtable 인코딩을 사용하여 저장한다.

반응형
반응형

프로메테우스란 무엇인가?


 프로메테우스는 메트릭 기반의 오픈소스 모니터링 시스템이다. 2012년 사운드클라우드사에서 개발을 시작한 후, 프로메테우스와 연관된 관련 커뮤니티와 생태계는 꾸준히 성장해 왔다. 프로메테우스는 주로 Go 언어로 작성되었으며 아파치 2.0 라이센스를 따른다. 또한 프로메테우스 프로젝트는 2016년에 클라우드 네이티브 컴퓨팅 재단의 두 번째 멤버가 되었다.

 

 

프로메테우스의 특징


  • a multi-dimensional data model with time series data identified by metric name and key/value pairs
    • 키/값 쌍의 메트릭이름으로 된 시계열데이터가 포함된 다차원-데이터-모델
  • PromQL, a flexible query language to leverage this dimensionality
    • 이러한 차원을 이용하는 유연한-질의-언어
  • no reliance on distributed storage; single server nodes are autonomous
    • 분산 저장장치에 의존하지않는;단일-서버-노드는 자율적이다.
  • time series collection happens via a pull model over HTTP
    • HTTP를 통한 pull-방식을 통해 시계열 수집이 발생한다.
  • pushing time series is supported via an intermediary gateway
    • 중계-게이트웨이를 통해 시계열 푸시가 지원된다.
  • targets are discovered via service discovery or static c도onfiguration
    • service-discovery와 정적구성을 통해 대상들이 발견된다.
  • multiple modes of graphing and dashboarding support
    • 다양한 그래프 모드와 대시보드를 지원한다.

 

 

프로메테우스의 구성요소


The Prometheus ecosystem consists of multiple components, many of which are optional:

Most Prometheus components are written in Go, making them easy to build and deploy as static binaries.

 

프로메테우스 아키텍쳐


 

프로메테우스 알림


 프로메테우스의 알림은 두부분으로 나누어져 있다. 프로메테우스의 알림규칙은 알림(경고)을 알림메니저로 보낸다. 그런다음 알림메니저는 사일런싱(silencing), 금지/억제(inhibition), 집계(aggregation)을 포함하여 알림 발송(email, slack, chat)을 관리한다.

 

따라서 알림과 통지를 설정을 구성해야 한다.

  • 알림메니저를 구성한다.
  • 알림메니저와 통신하도록 프로메테우스를 구성한다.
  • 프로메테우스에 알림규칙을 생성한다.

 

기록 규칙


 프로메테우스가 정기적으로 PromQL 표현식을 수행하고 결과를 수집하도록 기록규칙(recoring rules)을 사용할 수 있다. 기록규칙은 대시보드의 속도를 높이고, 다른 곳에 사용하기 위해 집계된 결과를 제공하며 범위 벡터 함수를 작성하는 데 유용하다. 알림규칙도 기록규칙의 변형이다.  기록규칙은 쿼리를 더 효율적으로 만들기 위해 카디널리티를 감소시키는 데 주로 사용된다. 기록 규칙은 대시보드와 페더레이션, 그리고 장기 저장소에 메트릭을 저장하기 전에 일반적으로 사용된다. 범위 벡터 함수를 작성하고 메트릭에 대한 API를 다른 팀에 제공하는 경우에도 기록 규칙을 사용할 수 있다.

 

알림이란?


문제가 발생했을 때 사람에게 통보해주는 기능이다. 프로메테우스는 지속적으로 계산이 수행되는 PromQL 형식으로 알림이 발생할 수 있는 조건을 정의할 수 있으며, 그 결과에 대한 시계열이 바로 알림이 된다. 

 

알림규칙


기록규칙과 동일한 규칙 그룹에 배치하고 원하는 방식으로 조화시킬 수 있다. 일반적으로 임의의 작업에 대한 모든 규칙과 알림을 하나의 그룹으로 표시한다. 만약 한 주기에 계산되기 어려울 정도로 그룹이 커지면, 그룹을 줄이는 것이 옵션이 아닐 경우, 그룹을 분할해야 할 수도 있다.

 

 알림매니저가 시간에 따른 알림 통보를 제공하지 않기 때문에 특정 시간에만 받기 원하는 경우 날짜함수를 사용해서 알림규칙을 설정해야 한다. 일반적으로 모든 알림에 대해 최소 5부의 for 값을 사용하는 것을 권장한다. 이렇게 하면 간단한 플랩을 포함한 대다수의 산출물에서 양성(false positive) 문제를 제거할 수 있다.(폭탄 알림 방지) 알림레이블을 추가해서 알림매니저를 구성할 때 사용할 수 있게 한다.

 

알림매니저


모든 프로메테우스 서버에서 알림을 모두 전달 받아 이메일이나 채팅 메시지, 또는 호출 등의 통보로 변환하는 것이 알림 매니저의 역할이다. 다시 말해서 알림이 통보로 변환되는 방법에 대해 제어 가능한 파이프라인을 사용자에게 제공한다.  파이프라인은 다음과 같다. 억제/금지(inhibition), 사일런싱(silencing), 라우팅(routing), 그룹화(grouping), 조절과 반복(throttling, repitition), 통보(notification)의 단계가 있다.

 

Tip


  • 프로메테우스의 구성 새로 로딩하기
  • kill -HUP <pid>--web.enable-lifecycle 플래그 지정 후 HTTP POST로 /-/reload 엔드포인트 보내기

 

반응형
반응형

RabbitMQ 설치 및 설정

1. 사용할 버전에 대한 tar.xz 파일을 다운받는다.

2. 압축을 풀고 원하는 디렉토리로 이동한다.

3. rabbitmq를 실행 및 종료한다.

rabbitmq_server/sbin/rabbitmq-server 명령어로 실행한다.
rabbitmq_server/sbin/rabbitmqctl shutdown 명령어로 실행한다.

4. rabbitmq 매니저 플러그인을 실행한다.

${HOME}/sbin/rabbitmq-plugins enable rabbitmq_management
* 별일 없으면 guest / guest 계정으로 로그인이 가능하다.

5. management UI에 로그인하기 위한 사용자를 추가한다.

${HOME}/sbin/rabbitmqctl add_user {username} {password}

6. 추가한 계정에 administrator 태그를 부여한다.(어드민 권한)

${HOME}/sbin/rabbitmqctl set_user_tags {username} administrator

7. 계정에 퍼미션을 추가한다. (UI 화면 메뉴가 잘 보인다.)

${HOME}/sbin/rabbitmqctl set_permissions -p / {username} ".*" ".*" ".*"
반응형
반응형

TensorFlow 설치

Python 설치 및 SymbolicLink 변경

다음의 위치에서 다운로드 및 설치

https://www.python.org/downloads/mac-osx/

심볼릭링크 변경하여 버전 확인
ln -s -f /usr/local/bin/python3.8 /usr/local/bin/python
python --version
ln -s -f /usr/local/bin/pip3.8 /usr/local/bin/pip
pip --version

Tensorflow 설치

Python이 설치되어 있다면 터미널에서 pip를 이용한 아래 명령어로 간단하게 tensorflow를 설치할 수 있습니다.

pip install tensorflow
python -m pip install --upgrade pip
pip show tensorflow

참고자료

한글블로그

https://tensorflow.blog/

한글번역문서

https://github.com/tensorflowkorea/tensorflow-kr
https://tensorflowkorea.gitbooks.io/tensorflow-kr/content/

반응형
반응형

Tensorflow

Tensorflow는 본래 Machine-learning과 Deep-neural-network 연구를 수행하는 구글 브레인 팀에서 개발되었습니다. Tensorflow는 데이터 플로우 그래프를 사용해서 수치 연산을 하는 라이브러리로 볼 수 있습니다. 그래프의 노드(node)는 수학적 연산을 나타내고 노드를 연결하는 그래프의 엣지(edge)는 다차원 데이터 배열(array)을 나타냅니다. Tensorflow는 수치연산을 기호로 표현한 그래프 구조를 만들고 처리한다는 기본 아이디어를 바탕으로 구현되었습니다. 그래서 텐서플로우는 CPU, GPU의 장점을 모두 이용할 수 있고 다양한 플랫폼에서 바로 사용될 수 있습니다.

Tensor란? 무엇인가

Tensor = n차원 행렬
Tensor는 n차원 행렬을 지칭하는 용어입니다.

  • 0-d tensor : scalar
  • 1-d tensor : vector
  • 2-d tensor : matrix

TensorFlow의 특징

  • End to end Machine learning platform
  • ML 모델을 개발하고 학습시키는 데 도움이 되는 핵심 오픈소스 라이브러리를 제공한다.
  • 손쉬운 모델 빌드
    • 즉각적인 모델 반복 및 손쉬운 디버깅을 가능하게 하는 즉시 실행 기능이 포함된 Keras와 같은 높은 수준의 직관적인 API를 사용하여 ML 모델을 쉽게 빌드하고 학습한다.

TensorFlow의 장점

경쟁 라이브러리와 비교했을 때 TensorFlow의 장점은 다음과 같습니다.

  1. 손쉬운 딥러닝 모델 구현을 가능하게 하는 PythonAPI 제공
  2. Mobile Device부터 멀티 GPU 클러스터까지 지원하는 폭넓은 Portability
  3. 강력한 시각화를 지원하는 TensorBoard 제공
  4. 전세계적으로 폭넓은 사용자 Community
  5. Google의 강력한 지원과 발빠른 신기능 업데이트

참고자료

한글블로그

https://tensorflow.blog/

한글번역문서

https://github.com/tensorflowkorea/tensorflow-kr
https://tensorflowkorea.gitbooks.io/tensorflow-kr/content/

반응형
반응형

1. RabbitMQ란?

RabbitMQ는 MOM(Message-Oriented-Middleware)의 하나로 느슨하게 결합된 아키텍쳐를 지향하는 AMQP Message-Broker입니다.

MOM은 분산시스템에서 메시지를 보내고 바을 수 있는 소프트웨어 또는 하드웨어 인프라를 말한다. RabbitMQ는 향상된 메시지 라우팅 및 분배기능을 제공하고 안정적인 분산 시스템을 지원하기 위해 광역 네트워크를 통해 다른 시스템과 손쉽게 연결할 수 있는 메시지 지향 미들웨어 중 하나다.

 

2. Loosely Coupled Architecture의 장점

부하분산을 제공하여 안정적인 성능을 낼 수 있도록 해 주며, 새로운 기능 추가 시 기존의 시스템과 의존성을 낮추게 해 줍니다.

 

3. AMQ 모델

RabbitMQ의 강점과 유연성등은 대부분 AMQP(Advanced Message Queuing) 모델을 살펴보면 확인할 수 있다. AMQ 모델은 메시지 라우팅 동작을 정의하는 메시지 브로커의 세 가지 추상 컴포넌트를 다음과 같이 논리적으로 정의한다.

  • 익스체인지 : 메시지 브로커에서 큐에 메시지를 전달하는 컴포넌트
    • direct exchange
    • fanout exchange
    • topic exchange
    • headers exchange
  • 큐 : 메시지를 저장하는 디스크상이나 메모리상의 자료구조
  • 바인딩 : 익스체인지에 전달된 메시지가 어떤 큐에 저장돼야 하는지 정의하는 컴포넌트

 

4. AMQP를 통한 RabbitMQ

RabbitMQ는 AMQP 메지시브로커로 서버와 통신하는 거의 모든 부분에서 RPC(Remote Procedure Call) 패턴으로 엄격하게 통신한다. AMPQ 스펙에는 클래스와 메소드를 사용하여 클라이언트와 서버 간의 공통 모델인 AMQP 명령이 정의돼 있다. RabbitMQ에서 AMQP 명령을 전송하거나 수신할 때 필요한 인자들은 데이터 구조로 캡슐화된 프레임으로 인코딩돼 전송되며 다섯 개의 구성 요소로 이루어져있다.

  • 프레임유형
  • 프레임크기
  • 프레임 페이로드
  • 채널번호
  • 끝 바이트 표식(ASCII값 206)
RabbitMQ를 이용해서 클라이언트 애플리케이션을 구현할 때는 복잡하게 너무 많은 채널을 사용하지 않는 것이 좋다고 한다. 각 채널마다 메모리 구조와 객체가 설정되어 있기 때문에 많을수록 메모리를 많이 사용하게 된다.

프레임유형에는 다섯가지 유형이 있다.

  • Protocol Header Frame
  • Method Frame
  • Contetn Header Frame
  • Body Frame
  • Heartbeat Frame

 

5. 메시지 속성값

Basic.Properties를 이해하여 RabbitMQ의 동작을 제어할 수 있습니다.
  • content-type : application/json
  • content-encoding : base64, gzip
  • message-id, correlation-id
  • timestamp
  • exparation
  • delivery-mode : 메모리저장 or 디스크저장(속도에 영향을 준다)
  • app-id, user-id
  • type
  • reply-to
  • headers
RabbitMQ의 다양한 용어와 설정에 대해 처음 접한다면, 메시지 속성(persistence)이 큐의 내구성(durable) 속성과 혼동될 수 있다. 큐의 durable 속성은 RabbitMQ 서버나 클러스터를 다시 시작한 후에도 큐 정의가 유지돼야 하는지를 나타내는 반면, delevery-mode는 메시지를 유지할지 여부를 나타낸다.

 

6. 메시지발행과 성능절충

  • Publisher가 메시지를 디스크에 저장해야 하는가?
  • 애플리케이션의 다양한 구성 요소는 발행된 메시지가 수신됐는지 보장해야 하는가?
  • TCP back-pressure로 애플리케이션이 차단되거나 RabbitMQ에 메시지를 발행하는 동안 연결이 차단된 경우 어떻게 되는가?
  • 메시지가 얼마나 중요한가? 메시지의 처리량을 높이기 위해 배달 보장을 희생할 수 있는가?
메시지 발행은 메시징 기반 아키텍처의 핵심 동작 중 하나로 RabbitMQ에는 메시지 발행에 대한 여러 설정이 있다. 애플리케이션에서 사용 가능한 다양한 메시지 발행 옵션은 애플리케이션의 성능과 안전성에 많은 영향을 준다. 메시지브로커는 빠른 성능이나 처리량도 중요하지만, 신뢰할 수 있는 메시지 전달도 중요한 지표 중 하나다.
  • Goldilocks Principle (ex. trade off?)
  • mandatory
  • delevery-mode
  • durable
  • alternative exchange
  • clustered HA queue
RabbitMQ와 원자 트랜젝션
원자성은 트랜잭션을 커밋하는 과정에서 트랜잭션의 모든 동작이 완료되는 것을 보장하는데, 이는 AMQP에서 트랜잭션의 모든 작업이 완료될 때까지 클라이언트가 TX.commitOK 응답 프레임을 받지 않는 다는 것을 의미한다. 불행하게도 RabbitMQ에 영향을 줄때만 원자 트랜잭션을 지원한다. 트랜잭션 명령이 둘 이상의 큐에 영향을 주면 커밋은 원자적으로 동작하지 않는다.

중략...

delevery-mode를 2로 설정해서 디스크에 저장해야 하는 메시지가 포함된 원자 트랙잭션은 Publisher의 성능에 문제를 일으킬 수도 있다. I/O가 부하가 많은 서버에서 RabbitMQ가 TX.CommitOK 프레임을 보내기 전에 쓰기가 완료될 때까지 기다리는 경우, 클라이언트는 트랜잭션으 ㄹ사용하지 않은 경우보다 오래 기다리게 된다.

RabbitMQ 푸시백

3.2부터 AMQP 스팩을 확장해 연결에 대한 크래딧이 임계값에 도달했을 때 전동되는 알림을 추가하고 클라이언트에 연결이 차단됐다는 사실을 알린다.

 

7. 메시지 Consume

  • 동기/비동기 (Basic.Get/Basic.Consume)
  • no_ack=True
  • linux socket buffer size
  • prefetch size (no-ack가 설정되면 무시)
  • Basic.Reject or Basic.Nack with redelivered flag
  • dead_letter_exchange / x-dead-letter-exchange / x-dead-letter-routing-key
  • auto-delete / x-expire
  • durability

 

반응형
반응형

Python과 Django

장고는 파이썬용 오픈소스 웹 개발 프레임워크로 웹 개발을 간단하고 쉽게 만든느 것이 목적이다. 장고는 동적 관리 인터페이스, 캐시 프레임워크, 단위 테스트 같은 특징을 포함하고 있다. 장고서버와 nginx를 uWSGI로 연동합니다.

 

uWSGI

uWSGI 모듈은 nginx와 애플리케이션이 uwsgi 프로토콜로 통신하게 해준다. uwsgi 프로토콜은 WSGI(Web Server Gateway Interface)에서 파생됐습니다.

 

SCGI

SCGI는 Simple Common Gateway Interface의 약자로 CGI 프로토콜의 변종이며 FastCGI와 유사하다. SCGI 인터페이스와 모듈은 Apache, IIS, Java, Cherokee등 다양한 소프트웨어 프로젝트에서 발견할 수 있습니다.

 

Python과 Django 설치 및 설정

  • yum install python3 python3-devel
  • yum install python3-pip
  • pip3 install django~=2.2.0
  • pip3 install uwsgi
  • django-admin startproject test_project
  • cd test_project/
  • uwsgi --socket :9000 -p 5 --module test_project.wsgi &
  • ps aux | grep uwsgi

참고

uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html

 

반응형
반응형

PHP와 nginx의 연동 

FastCGI를 사용해 PHP를 nginx와 연동해 보려고 합니다. 기본적으로 PHP는 FastCGI 프로코콜을 지원합니다.PHP는 스크립트를 처리하며 nginx와 socket으로 연동할 수 있습니다. 바로 PHP-FPM으로도 알려진 FastCGI 프로세스 관리자를 사용하면 됩니다.

PHP-FPM

PHP 프로세스를 관리하는 스크립트로서 nginx의 요청을 받은 후 스크립트를 수행합니다. 
  • PHP의 자동 데몬 프로세스화(백그라운드 프로세스로 전환)
  • chroot로 격리된 환경에서 스크립트를 수행
  • 로그개선, IP주소제한, Pool분리등

PHP 설치 및 빌드

공식문서 : www.php.net/manual/en/install.unix.nginx.php

다운로드 및 압축을 푼다

  • yum install libevent-devel libxml2-devel
  • wget www.php.net/distributions/php-7.4.14.tar.gz
  • tar xzf php-7.4.14.tar.gz

빌드과정을 수행한다

  • ./configure --enable-fpm --with-mysqli
    • 에러 발생 시 .. No package 'sqlite3' found
      • sudo yum -y install sqlite-devel 
  • make
  • make install

기본설정 파일을 복사한다

  • cp php.ini-development /usr/local/php/php.ini
  • cp /usr/local/etc/php-fpm.d/www.conf.default /usr/local/etc/php-fpm.d/www.conf
  • cp sapi/fpm/php-fpm /usr/local/bin

보안을 위해 php.ini 파일을 수정한다

  • vim /usr/local/php/php.ini
  • cgi.fix_pathinfo=0

php-fpm.conf 파일을 수정한다

vi /usr/local/etc/php-fpm.d/www.conf
  • user = www-data
  • group = www-data

php-fpm 실행

 /usr/local/sbin/php-fpm -c /usr/local/etc/php.ini --pid /usr/local/var/run/php-fpm.pid --fpm-config=/usr/local/etc/php-fpm.d/www.conf -D
  • -c /usr/local/etc/php.ini    #PHP 구성파일의 경로지정
  • --pid /usr/local/var/run/php-fpm.pid    #초기화 스크립트에서 프로세스를 제어하는 데 유용한 PID 파일의 경로지정
  • --fpm-config=/usr/local/etc/php-fpm.d/www.conf    #PHP-FPM이 특정 구성파일을 사용하도록 강제지정
  • -D    #PHP-FPM을 데몬화

Nginx 설정 수정

user www-data;

http {
	server {
    	listen 80;
        server_name localhost;
        
        location / {
            root html;
            index index.php index.html index.htm;
        }
        
        location ~* \.php$ {
            fastcgi_index   index.php;
            fastcgi_pass    127.0.0.1:9000;
            include         fastcgi_params;
            fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param   SCRIPT_NAME $fastcgi_script_name;
            fastcgi_param   PATH_INFO $fastcgi_script_name;
        }
    }
}

Nginx 실행

/usr/local/nginx/sbin/nginx  또는 /usr/local/nginx/sbin/nginx -s reload

 

반응형
반응형

설정 버전 상세 확인

다음의 명령을 통해 상세한 버전 및 모듈에 대해서 확인 가능합니다.

/usr/local/nginx/sbin/nginx -V

 

설정 파일 테스트

설정 파일의 유효성을 테스트를 통해 잘못된 부분이 없는지 확인합니다.

/usr/local/nginx/sbin/nginx/ -t

 

운영중일 때 교체하는 법 1

새 파일을 생성 후 테스트 하고, 교체 후 업데이트 하도록 합니다. master 프로세스의 PID 변경없이 가능합니다.

  • /usr/local/nginx/sbin/nginx -t -c /home/anybody/test.conf
  • cp -i /home/anybody/test.conf /usr/local/nginx/conf/nginx.conf
  • /usr/local/nginx/sbin/nginx -s reload

 

운영중일 때 교체하는 법 2

새 파일을 생성 후 테스트 하고, 교체 후 kill 명령어를 수행합니다.

  • /usr/local/nginx/sbin/nginx -t -c /home/anybody/test.conf
  • cp -i /home/anybody/test.conf /usr/local/nginx/conf/nginx.conf
  • master 프로세스의 PID를 확인한다.
  • kill -USR2 {PID} 명령으로 master 프로세스에게 USR2(12)-시그널을 보낸다.
  • kill -WINCH {PID} 명령으로 master 프로세스에게 WINCH(28)- 시그널을 보낸다.
  • kill -QUIT {PID} 명령으로 master 프로세스에게 WINCH(28)- 시그널을 보낸다.

 

반응형
반응형

설정 파일 목록

Centos에 nginx를 설치하게되면 /usr/local/nginx/conf에 설정파일들이 위치하게 됩니다.

파일명 설명
nginx.conf 웹 서버의 기본 구성
mime.types 파일 확장자와 연관된 MIME 타입의 목록
fastcgi_params Fast CGI 관련 구성
proxy.conf 프록시 관련 구성
sites.conf nginx로 제공되는 웹 사이트(v호스트) 구성, 도메인 단위로 분리하기를 권장

 

Base-Module

nginx는 기본적으로 master 프로세스와 worker 프로세스로 동작하기 때문에 기본적인 동작과 설정은 이해할 필요가 있습니다. nginx의 기본적인 기능들을 정의하도록 지시어를 제공하고 크게 3가지로 분류합니다.

  • core-module : 프로세스 관리나 보안같은 필수 기능 및 지시어로 이루어져있다.
    • master_process {on|off};
    • thread_pool {name} threads={number} max_queue={number};
    • worker_processes {number | auto};
  • event-module : 네트워크 기능의 내부 동작 방식을 구성한다.
    • use {select | poll | epoll | kqueue | rtsig | /dev/poll | eventport}
  • configuration-module : 구성을 외부 파일에서 가져와 포함시킨다.

 

꼭 확인해야 할 설정값들

  • user root root;
    • 파일시스템 전체 권한을 nginx에 부여하기 때문에 보안상 취약함
  • worker_processes 1;
    • 멀티코어 환경에서 CPU의 코어1개로 실행됨을 의미한다. auto로 하거나 코어수에 맞춘다.
  • worker_priority 0;
    • 시스템의 다른 프로세스 실행순서를 고려하여 설정하라. -20~19  사이로 설정 가능하며, 커널프로세스가 -5의 우선순위를 갖기 때문에 더 낮은 값은 설정하면 안 된다.
  • log_not_found on;
    • 404 errors 로그를 남길 것인지 아닌지 지정한다. 쓸데없는 로그가 남을 수 있기 때문에 주의해야 한다.
  • worker_connections 1024;
    • worker 프로세스의 수와 함께 서버가 동시에 수용할 수 있는 연결 수를 결정한다. worker당 연결수이다.

 

기본 nginx.conf 예시

더보기

http {

    include mime.types;

    default_type application/octet-stream;

    sendfile on;

    keepalive_timeout 65;

    server {

        listen 80;

        server_name localhost;

        location / {

            root html

            index index.html index.htm

        }

        error_page 500 502  503 504 /50x.html;

        location = /50x.html {

            root html;

        }

    }

}

 

 

반응형
반응형

 

필수 구성요소 설치

간단하게 yum install nginx 명령어로 설치가능합니다. 그러나 직접 nginx 설치 파일을 다운로드 받았을 때는 다음의 라이브러리들을 먼저 설치해야 합니다.

  • yum groupinstall "Development Tools"
  • yum install pcre pcre-devel
  • yum install zlib zlib-devel
  • yum install openssl openssl-devel

 

nginx 다운로드

다음의 페이지에서 원하는 버전을 찾아 다운로드하고 압축을 풀어줍니다.

http://nginx.org/en/download.html

  • wget http://nginx.org/download/nginx-1.18.0.tar.gz
  • tar zxf nginx-1.18.0.tar.gz

 

설치 및 설정

참고로 configure 명령을 통해 여러가지 옵션을 줄 수 있습니다.

  • nginx-1.18.0/configure 
  • nginx-1.18.0/make
  • nginx-1.18.0/make install

 

실행 및 종료

Centos에서는 /usr/local/nginx/ 디렉토리에 설치가 완료되어 실행 가능합니다.

참고로 대부분의 유닉스 계열 시스템에서 프로세스는 root 계정으로 TCP 소켓 포트를 열 수 있다. 

  • 실행
    • /usr/local/nginx/sbin/nginx 
    • sudo nginx
  • 종료1 : /usr/local/nginx/sbin/nginx -s stop (TERM 시그널을 사용하여 강제로 종료한다)
  • 종료2 : /usr/local/nginx/sbin/nginx  -s quit (QUIT 시그널을 사용하여 안전하게 종료한다)

 

실행 후 확인

  • 브라우저로 호스트에 접근하여 welcome 페이지를 확인한다.
  • ps -ef | grep nginx 로 프로세스를 확인한다.
반응형
반응형

Git Config

  • 설정 목록 확인
    • git confi --list
  • 사용자정보 변경
    • git config  --global user.name "이름"
    • git config --global user.email "이메일@"
  • 비밀번호 재설정
    • git config --global --unset user.password

 

 

Git History

  • 커밋 히스토리가 중요한 이유는?
    • 의미있는 커밋을 만들어서 운영하는데 도움이 되고자 한다.버그가 언제 터졌는지 파악하기 쉽다.레거시 코드를 수정할 때...
  • 히스토리를 깔끔하게 만드는 3가지 머지 전략
    • Create a merge commit
    • Squash and merge
    • Rebase and merge

 

 

Git Rebase 

  • 로그 합치기
    • git rebase -i {원하는커밋로그의 바로 전 로그}
    • 합쳐질 것들을 squash 로 설정하여 저장 후 인터렉티브모드 종료
    • git status 로 수행할 명령어 확인
    • 이전 로그 메시지 수정하기
    • 수정할 것을 edit 로 하고 메시지 수정 후 인터렉티브모드 종료
    • git status 로 수행할 명령어 확인
    • git commit --amend 수행
    • git rebase --continue 수행정상적으로 메시지 수정 완료

 

Git Tag

 

Git Graph

  • git log --graph --oneline
  • git log --oneline --decorate

 

Git Rename - 브랜치 이름 변경하기

  • 다른 브랜치에서 바꾸고 싶은 브랜치 이름 변경하기
    • git branch -m {old-name} {new-name}
  • 현재 브랜치의 이름 바꾸기
    • git branch -m {new-name}

 

Git Reset vs Revert

둘다 되돌리기 이나 Reset은 history는 유지하지 않으나 Revert는 history를 유지한채 수행된다.

  • git reset --soft
    • stage 상태로 되돌린다.
  • git reset --mixed
    • unstaged 상태로 되돌린다.
  • git reset --hard
    • 이전 history를 삭제하고 되돌린다.
  • git revert
    • 바로 전 commit에 대해 revert해야하고 건너뛰어 더 이전의 commit을 revert하면 conflict가 발생한다.

 

Git Force Commit

  • 가장 최근 커밋 내역 되돌리기
    • git reset HEAD^
  • 리모트 강제 푸시
    • git push -f origin {BranchName}

 

Git commit log copy

  • git cherry-pick {commit-log}

 

Git Errors

  • -- fatal: refusing to merge unrelated histories
    • git pull origin {branch} --allow-unrelated-histories

 

Git flow 

 

 

 

반응형

+ Recent posts