PangYeon`s IT Log

Docker 대신 image를 만들 수 있는 도구

기본적으로 Docker 명령어와 동일한 듯 하다.

1. install

sudo apt install buildah

2. build

buildah build -f Dockerfile -t fedora-httpd .
# or
buildah build -t fedora-httpd

3. push 

buildah push registry.example.com/my_image

https://github.com/containers/buildah/blob/main/docs/tutorials/01-intro.md

https://github.com/containers/buildah/blob/main/docs/buildah-push.1.md

1. Docker 아키텍쳐 pull

docker pull --platform linux/amd64 nginx:latest

2. Docker image 저장

docker save -o a.tar imagenams

3. Docker image 업로드

docker load -i a.tar

4. Docker image 태그 변경

docker image tag imageid a:1.0

주로 사용하던 sed 명령어들

1. sed 수정

sed -i 's/ver: 1.0.0/ver: 1.0.1' /home/user/test.conf

2. sed 특정 글 위에추가, 특정 글 아래 추가

특정 글 위에 추가

sed -i -r -e '/ver: 1.0.1/i\Description: version' /home/user/test.conf

특정글 아래 추가

sed -i -r -e '/ver: 1.0.1/a\End Of File' /home/user/test.conf

3. 특정 글 아래 수정

sed -i '/Description: version/{ n; s/ver: 1.0.1/version: 1.0.1/I}' /home/user/test.conf

4.  띄어쓰기(space) 입력

기본적으로 한줄이면 그냥 스페이스바 입력으로 되지만, 그게 아니라면 역슬래쉬(\)를 해주어야 함.

# 한 줄로 작성할 경우
sed -i -r -e '/version: 1.0.1/a\  Date: 2024' /home/user/test.conf

# 여러 줄로 작성할 경우
sed -i -r -e '/Date: 2024/a\
\ \ Month: 4(April)' /home/user/test.conf

최종 결과물

Nginx의 auth_request 기능을 사용하고 싶었지만, apache에는 이와 비슷한 기능이 없는 것 같아

AuthType이라는것을 사용하였다.

1. 사용전 htpasswd 확인

htpasswd는 기본적으로 Apach생성 경로의 bin폴더에 있다.

# Apache 가 /usr/local 폴더에 있을경우
/usr/local/apache/bin/htpasswd

bin폴더에 없을경우 httpd를 설치한다. - https://httpd.apache.org/download.cgi#apache24

2. htpasswd를 통해 계정과 비밀번호를 생성

-c 는 create 옵션이고 /home/test 폴더 내에 .htpasswd 파일을 생성하고

해당 파일에 user1이라는 계정과 패스워드를 관리한다

# Input
./htpasswd -c /home/test/.htpasswd user1

# Output
cat /home/test.htpasswd
user1:$apr1$.0CAabqX$rsdf8sdSDFgs/p90SDGcvb1Gs/

3. AuthType 설정

사용 중인 conf파일에 설정 후 아파치 재시작한다.

<Location "/private">

AuthType Basic
AuthName "Authentication required"
AuthUserFile /home/test/.htpasswd
Require valid-uesr

</Location>

기타.

이렇게 설정할 경우 기본적으로 웹사이트에 로그인하는 로직이 있다면 해당 세션이 끊기게되는데

아래 설정을 추가할 경우 해결할 수 있긴하다.

RequestHeader unset Authorization
<Location "/private">

AuthType Basic
AuthName "Authentication required"
AuthUserFile /home/test/.htpasswd
Require valid-uesr

</Location>

https://httpd.apache.org/docs/2.4/en/howto/auth.html

Java에서 Inner Class 사용시 발생하는 No enclosing instance of type is accessible 해결 방법이다.

아래와 같이 java 파일들이 구성되어있고 Hello.java 파일안에 World 라는 inner class가 있을 경우

public class Hello {
	private int id;

	public Hello() {
		super();
	}

	public Hello(int id) {
		super();
		this.id = id;
	}

	public int getId() {
		return id;
	}

	public void setId(int id) {
		this.id = id;
	}

	public class World {		
		private String name;

		public World() {
			super();
		}

		public World(String name) {
			super();
			this.name = name;
		}

		public String getName() {
			return name;
		}

		public void setName(String name) {
			this.name = name;
		}			
		
	}
}

Hello안에있는 World Class를 사용하기 위해서 Hello Class를 먼저 생성 후 World Class를 호출한다.

import test3.Hello.World;

public class Main {

	public static void main(String[] args) {

		Hello hello = new Hello();
		World world = hello.new World();
				
	}

}

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

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"]]
                ])
            }
        }

    }
}

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가 동일하다는 것을 볼 수 있다.