Nginx에서 client에서 파일 업로드와 같은 작업 수행시

응답으로는 이미 max_client_body_size 설정으로 에러인 상황에서 Request가 중단되어야하지만

Request가 끝까지 진행되는 경우가 있는데

이 경우 send_timeout, proxy_send_timeout, proxy_connect_timeout, client_body_timeout 등의 설정이아니라

lingering_time으로 설정해야한다.

Syntax:	lingering_time time;
Default: lingering_time 30s;
Context: http, server, location

This directive applies to client requests with a request body. As soon as the number of uploaded data exceeds max_client_body_size, Nginx immediately sends a 413 Request entity too large HTTP error response. However, most browsers continue uploading data regardless of that notification. This directive defines the number of time Nginx should wait after sending this error response before closing the connection.

http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_time

https://www.oreilly.com/library/view/nginx-http-server/9781788623551/97c141a3-0e51-4786-b865-8c8770a643a5.xhtml

Maven, Npm - 2020.12.05 - [Develop/기타 작업] - Nexus bulk upload (Nexus 대량 업로드)

whl확장자로 되어있는 Python Package Upload 를 위해서는 Python Package 중 twine 이라는 Package를 이용한다.

1. 인터넷이 되는 환경에서는 아래 명령어로 설치하면된다.

pip install twine

2. 인터넷이 되지 않는 Offline 환경에서는 먼저 인터넷이 되는 환경에서 whl파일을 내려받아야한다.

아래명령어를 통해 twine 설치에 필요한 패키지들을 전부 받는다. 

pip download -d . twine

받고난 뒤 설치하면 패키지가 3개정도 없다고 나오는데 (twine 4.0.3버전 기준) 

해당 패키지 3개 또한 https://pypi.org/project/ 에서 whl 파일을 미리 받아서 Offline 환경으로 반입한다.

없는 패키지 목록은 아래와 같다

pypiwin32-223-py3-none-any.whl
pywin32_ctypes-0.2.0-py2.py3-none-any.whl
charset_normalizer-3.1.0-py3-none-any.whl

3. Offline 환경에서 아래 명령어를 입력한다.

pip install --no-index -f . twine

만약 설치 후 없는 파일이 존재하면 마찬가지로 반입하여 설치하면된다.

4. 설치 후에 .pypi 파일을 작성한다

'C:\Users\window계정' 해당 경로에 .pypi를 작성한다.

[distutils]
index-servers =
    nexuslabel


[nexuslabel]
repository : http://nexus.url
username : id
password : pw

5. 업로드할 whl 폴더에 터미널을 열어 아래의 명령어를 실행한다.

만약 whl 파일들이 폴더안에 아무런 폴더구조를 가지지 않으면 ./* 로 실행하고

폴더 구조를 2단계로 가지고 있으면 ./*/* (e.g. test/test.whl)

폴더 구조를 3단계로 가지고 있으면 ./*/*/* (e.g. test/2.0/test.whl)

로 실행한다

twine upload --repository nexuslabel ./*

티스토리 댓글 알림 기능이다.

해당 기능은 티스토리의 square skin에만 가능하며, 슬랙으로만 알림 가능하다.

사용방법은 아래 github의 github actions로 사용가능하다.

https://github.com/wonkwangyeon/tistory-comment-notify

tistory comment notify

only square skin

티스토리 square skin 댓글 알림

Features

월 ~ 금 09~18시 의 59분에 실행된다.

티스토리 squre skin 기준으로 한시간마다 좌측의 최근 댓글 수집 후 Slack 채널로 알림 발송

How to use

Develop

root 경로에 .env파일 생성 후 아래 환경변수 세팅

WEBHOOK_URI=slack webhook uri 입력

CHANNEL=채널 입력

USER_NAME=채널에서 표시될 이름 입력

URL=tistory url 입력

NODE_ENV=dev

Production

Github actions repository secrets 설정

WEBHOOK_URI=slack webhook uri 입력

CHANNEL=채널 입력

USER_NAME=채널에서 표시될 이름 입력

URL=tistory url 입력

Crontab 설정

현재 Gitbucb actions crontab 부분에 월 ~ 금 09~18시 59분으로 설정되어있다.

원하는 시간있다면 Github actions 의 cron부분을 수정하면 된다.

시크릿(Secret) - https://kubernetes.io/ko/docs/concepts/configuration/secret/

시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 파드 명세나 컨테이너 이미지에 포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를 애플리케이션 코드에 넣을 필요가 없음을 뜻한다.

쿠버네티스에서 Deployment.yaml 작성시 Private Docker Registry, Nexus, Harbor 와 같은 것에 있는 이미지를 가져올 때Pull 권한이 없다고 하는 경우가 있다. 이 경우 secret 생성 후  deployment.yaml에 imagePullSecrets를 입력하면된다.(물론 모든 Worker Node에 docker login해주면되긴하지만, 항상 해당 registry 만 사용할건아니니까...)

1. secret 생성

secret 생성시 주의할 점은 namespace가 있을 경우 뒤에 -n 옵션을 통해 namespace를 설정해주어야한다.

없으면 default로 설정되며, 해당 pod가 namespace를 가질 경우 반드시 namespace를 설정해주어야한다.

1.1 default

kubectl create secret docker-registry secret-name \
  --docker-email=test@test.com \  # 이 부분은 생략가능
  --docker-username=harborId \ 
  --docker-password=harborPw \
  --docker-server=http://harborurl.com  # harbor or nexus or private registry

1.2 namesapce

kubectl create secret docker-registry secret-name \
  --docker-email=test@test.com \  # 이 부분은 생략가능
  --docker-username=harborId \ 
  --docker-password=harborPw \
  --docker-server=http://harborurl.com \ # harbor or nexus or private registry
  -n namespaceoption

2. imagePullSecrets 추가

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: test
        image: harborurl.com:latest
      imagePullSecrets:
      - name: secret-name # secret에서 생성한 이름

Nginx Ingress Controller 사용시 Nginx 와 관련된 기본적인 설정할 때 Annotaions기능을 통해 적용할 수 있다

예를들면 기본적으로 Nginx Ingress Controller 에 client_max_body_size 가 1m로 설정되어있는데,

ingress.yaml 의 Annotations을 통해 Nginx Controller Pod에 접속하지 않아도 Nginx 설정을 할 수 있다.

단, Nginx Ingress Controller의 경우 kubernetes Ingress Controller(Community Version)와

Nginx Ingress Controller가 있는데, 이를 잘 보고 적용해야한다.

1. kubernetes Ingress Controller(Community Version)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-with-annotations
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 8m   
spec:
  rules:
     ...

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/

2. Nginx Ingress Controller

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress-with-annotations
  annotations:
    nginx.org/client-max-body-size: 4m
spec:
  rules:
     ...

https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations

Nginx Error Page 처리방법으로는 error_page를 먼저 선언하고 뒤에 에러코드

그리고 표시할 html 파일 이름을 작성한 후 location을 선언한다.

location 안에는 html 파일경로를 작성한다.

또한, 한번에 여러 에러를 같은 페이지로 처리하기 위해서는 500 501 502 이런식으로 선언하여 사용한다.

server {

    error_page 400 /error_400.html;
    location = /error_400.html {
        root /usr/error/;
    }
    
    error_page 404 /error_404.html;
    location = /error_404.html {
    	root /usr/error/;
    }
    
    error_page 500 501 502 /error_500.html;
    location = /error_500.html {
    	root /usr/error/;
    }
}

간혹 에러페이지를 선언하였지만, 해당 에러페이지로 가지 않을 땐

발생하는 해당 location에 proxy_intercept_errors on;을 선언한다.

server {

	
    error_page 400 /error_400.html;
    location = /error_400.html {
        root /usr/error/;
    }
    
    error_page 404 /error_404.html;
    location = /error_404.html {
    	root /usr/error/;
    }
    
    error_page 500 501 502 /error_500.html;
    location = /error_500.html {
    	root /usr/error/;
    }
    
    location /api/test {
    	proxy_intercept_errors on;
    }
}

Jenknis 에서 Git Checkout 할 경우 파일 용량이 클 때 아래와 같이 기본으로 사용할 경우 10분이 넘어갈 경우 timeout 이 발생한다.

pipeline {
    agent any 
    stages {
        stage('checkout') { 
            steps {
                git branch: 'master', credentialsId: 'credentialsId', url: 'git Repo URL"
            }
        }

    }
}

이를 해결하기 위해 스크립트를 사용할 경우 아래와 같이 사용하여 timeout 시간을 늘려준다.

pipeline {
    agent any 
    stages {
        stage('checkout') { 
            steps {
                checkout([
                	$class: "GitSCM",
                	branche: [[name: "master"]],
                	extensions: [
                    	[$class: "CheckoutOption", timeout: 120],
                    	[$class: "CloneOption", timeout: 120]
                    ],
                	gitTool "Default",
                	userRemoteConfigs: [[credentialsId: "credentialsId", url: "git Repo URL"]]
                ])
            }
        }

    }
}

1. Label Selector

kubectl get nodes --show-labels

kubectl label ndoes [nodeName] [key=value]

spec:
  nodeSelector:
    key: value

2. cordon / uncordon

kubectl cordon [nodeName]

kubectl uncordon [nodeName]

3. Affinity

Windows 에서의 Android Studio에서 발생하는 'unable to find valid certification path to requested target' 에러 해결방법

1. Chrome에서 아무 사이트 접속하여 상단의 자물쇠 모양을 마우스 우클릭한다.

2. 이 사이트는 보안 연결(HTTPS)이 사용되었습니다. 클릭

3. 인증서가 유효함 클릭

4.인증서 창에서 상단의 '인증경로'로 접속한후 '맨위의 항목'을 클릭한 다음 '인증서 보기' 클릭

5. 창이 하나 더 나타나며, 상단의 '자세히' 클릭 후 '파일에 복사' 클릭

6. 인증서 내보내기 마법사에서 먼저 다음 누른 뒤 Base 64로 인코딩된 X.509로 바탕화면이든 아무곳에 저장

7. Android Stuido에서 해당 프로젝트 우클릭 후 Open Module Settings 클릭

8. 좌측 메뉴의 SDK Location 클릭 후 JDK location 확인

'C:\Program Files\Android\Android Studio\jre'

9. C:\Program Files\Android\Android Studio\jre 폴더로 이동 후 bin폴더로 이동

-> C:\Program Files\Android\Android Studio\jre\bin 으로 이동

bin폴더에 keytools.exe가 있음

C:\Program Files\Android\Android Studio\jre\bin 에서 폴더 Windows PowerShell 관리자로 열기

10. keytool 명령어 입력

cacert 파일은 jre\lib\security 폴더에 들어가면 확인할 수 있는데 아래의 명령어를 통해 cacert에 인증서 등록

-file 옵션에는 아까 저장한 인증서 경로를 적으면되고 -alias 옵션을 통해 별칭 저장

또한, 입력하게 되면 패스워드를 입력하라고 하는데 패스워드는 changeit 이다

Password : changeit

.\keytool -import -keystore "C:\Program Files\Android\Android Studio\jre\lib\security" -file "C:\Users\root\Desktop\testcert.cer" -alias testcert

11. 저장 후 안되면 재부팅 또는 Android Studio를 종료 후 다시 실행

.

Jenkins 에서 Lambda Plugin을 사용한 코드배포 및 함수 실행이다.

1. 람다 생성 및 기본적인 플러그인 세팅

1.1) jenkinsTest 람다 함수생성

1.2) Jenkins Lambda Plugin 세팅

2. 파이프라인 세팅

pipeline {
    agent any
    
    stages {
        stage('Git CheckOut'){
            steps{
                git branch: 'main', url: 'https://github.com/ / .git'
            }
        }
        stage('Make .zip'){
            steps{
                zip zipFile: 'test.zip'
            }
        }
        stage('lambda deploy'){
            steps{
                 withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'pangyeon',
                    accessKeyVariable: 'AWS_ACCESS_KEY_ID', secretKeyVariable: 'AWS_SECRET_ACCESS_KEY']]){
                    deployLambda(
                        awsRegion: 'ap-northeast-2',
                        awsAccessKeyId: "${AWS_ACCESS_KEY_ID}",
                        awsSecretKey: "${AWS_SECRET_ACCESS_KEY}",
                        functionName: 'jenkinsTest',
                        artifactLocation: 'test.zip',
                        updateMode: 'code'
                    )
                }
            }
        }
        stage('lambda invoke'){
            steps{
                withAWS(region:'ap-northeast-2', credentials:'pangyeon') {
                    invokeLambda(
                        functionName: 'jenkinsTest'
                    )
                }
            }
        }
    }
    post { 
        always { 
            sh 'rm test.zip'
        }
    }
}

3. 실행

4. 배포 확인

4.1) 이전 코드

4.2) 배포 후 코드

5. 실행 확인

5.1) Jenkins 실행 로그

RequestId : d019e541-92df-4fac-9021-96f150b793c2

5.2) Lambda 로그

RequestId :  d019e541-92df-4fac-9021-96f150b793c2

5.1, 5.2의 RequestId가 동일하다는 것을 볼 수 있다.