Copy Coding

Visual Studio Code로 파일을 불러왔는데 한글이 깨지면서 아래처럼 모두 물음표로 나오는 경우가 있습니다.

    //id �� �� ����

    $("#input_id").val("set input Value by id");

    //class �� �� ����

    $(".input_class").val("set input Value by class");

    //name���� �� ����

    $('input[name="input_name"]').val("set input Value by name");

Visual Studio Code 프로그램의 언어 설정은 프로그램 하단 우측을 보면 확인하면 알 수 있습니다.

그림에서 보이는 것처럼 현재 VS Code의 언어 설정은 UTF-8로 되어있지만 한글이 깨지는 경우입니다.

이런 경우 불러온 파일의 생성을 UTF-8가 아닌 다른 언어로 설정하여 작업했기 때문에 한글이 깨지는 상황입니다.

원래의 한글 인코딩을 찾기 위해서는 하단에 있는 인코딩 상태 값의 [UTF-8]을 클릭하면 상단 가운데에 다음처럼 [Reopen with Encoding] 메뉴를 볼 수 있습니다.

[Reopen width Encoding]을 클릭하면 문서의 인코딩을 변경할 수 있는 character set 값들이 나오는데

가능하면 한글 인코딩 설정을 먼저 선택해 보고 안되면 가능성 있는 인코딩 값을 선택합니다.

목록에서 [Korean (EUC-KR)을 찾아서 선택해 보았습니다.

    //id 로 값 설정

    $("#input_id").val("set input Value by id");

    //class 로 값 설정

    $(".input_class").val("set input Value by class");

    //name으로 값 설정

    $('input[name="input_name"]').val("set input Value by name");

이제 한글이 제대로 보이는군요.

- copy coding -

Nginx를 설치하기 위해 검색을 하면 두개의 사이트가 보입니다.

하나는 https://www.nginx.com/  이고 다른 하나는 https://nginx.org/ 인데 첫번째 주소는 제품군에 대한 소개 사이트이고 프로그램 다운로드를 위해서는 두번째인 https://nginx.org/ 사이트에 접속해야 합니다.

사이트는 텍스트로만 이루어져 있고 우측 메뉴에서 [download]를 클릭합니다.

아니면 처음부터 https://nginx.org/en/download.html 이 주소를 입력하여 사이트로 이동해도 됩니다. 

이 주소는 오늘 설명할 윈도우에 설치하는 파일을 다운로드 할 수 있는 곳이고 리눅스 설치 버전을 다운 받으려면 https://nginx.org/en/linux_packages.html 이곳으로 가면 됩니다. 

다운로드 페이지 상단에는 2개의 최신 버전이 제공됩니다.

Mainline version은 현재 작업중인 진짜 최신 버전이고 Stable version은 안정성이 확인된 차상위 버전입니다.

오늘 주제가 “nginx 어디까지 왔나”가 아니므로 Stable version을 다운로드 받습니다.

다운로드 할때도 2개가 있어서 어느 것을 다운받아야 할지 고민하게 되는군요.

nginx-1.24.0 이건 소스 코드이고 tar로 압축되어 있습니다.

nginx/Windows-1.24.0 이게 윈도우에서 바로 사용할 수 있는 응용 프로그램입니다.  이걸 받으면 됩니다.

심심한데 두개를 다 받아서 압축을 풀어서 비교해보면

서로 파일 내용이 다른걸 확인할 수 있습니다.

이것으로 설치가 완료됩니다.  그냥 적당한 폴더를 찾거나 생성해서 압축을 풀어주면 됩니다.

Nginx 파일을 실행하기 위해 마우스로 더블클릭 해봅니다.

아무것도 보이지 않으면 정상적으로 실행된 것입니다.

[작업관리자]를 띄웠다면 앱 영역이 아닌 백그라운드 프로세스에서 찾아야 합니다.

소리소문 없이 실행을 하고 있습니다.

진짜 잘 실행을 하고 있는지 확인을 하기 위해 웹브라우져를 하나 열고 127.0.0.1을 입력해 봅니다.

위와 같은 화면을 볼 수 있다면 정상적으로 작동하고 있는 것입니다.

어떻게 설정이 되어있어서 화면을 볼 수 있는지 환경설정을 알아보겠습니다.

conf 폴더 아래의 nginx.conf 파일을 열어 봅니다.

대부분 주석 처리가 되어있는데 server라는 항목을 보면

listen 80은 port 번호입니다.  web 기본 포트로 설정이 되어있군요.

server_name localhost는 url로 127.0.0.1이 되겠죠.

조금 아래에 location이 보입니다.

/ : URL을 127.0.0.1(localhost)로 들어오면

root html; html 이라는 폴더가 메인이라는 것이고

index index.html index.htm; 이건 첫 페이지는 index.html 또는 index.htm 이라는것입니다.

http://127.0.0.1 또는 http://localhost로 접속하면 html 폴더에 있는 index.html 파일을 보여주라고 되어 있습니다.

한번 그 위치가 어디인지 찾아봅니다.

대충 알것 같습니다. nginx.exe 파일을 기준으로 html 폴더와 그 내부에 index.html 파일이 보이는군요.

좀더 테스트를 위해 일단 nginx를 종료해봅니다.

필수적인 명령어는 다음과 같습니다.

nginx -s quit 명령을 이용하여 종료합니다.

그리고 nginx.conf 파일을 수정합니다.

수정된 nginx.conf에 맞추어 폴더와 파일을 생성합니다.

[D:\workspace\main + /login/ + file 명] 이렇게 폴더 구조와 파일을 만들면 되겠네요.

http://127.0.0.1/login/login.html

login.html 파일 내용도 추가합니다.

이제 nginx를 다시 실행해 봅니다.

C:\Users\USER\Downloads\nginx-1.24.0>nginx

오류 없이 실행이 되었습니다.

웹브라우져에서 확인해 봅니다.  http://127.0.0.1/login/login.html 을 입력합니다.

잘 나오는군요.

- copy coding -

별로 사용할 일이 없어서 필요할때마다 사용법을 찾아야 하는 번거로움이 있어서 시간이 많이 낭비되는것 같아 한번 정리를 해 봅니다.

1. crontab 문법

crontab은 아래와 같은 형태로 작성을 합니다.

* * * * * python3 /home/copycoding/test.py

애스터리스크(*) 모양이 5개인대 처음부터 하나씩 의미하는 내용은 아래 표와 같습니다.

요일이 맨 마지막에 위치하고 0:일요일, 1:월요일, 2:화요일.... 이렇게 해서 7:일요일 까지입니다.

*은 해당 항목의 조건에 모두 실행한다는 뜻입니다. (매분, 매시간, 매일, 매월, 모든요일.)

2. crontab 사용 방법

여기서 첫번째 분(minute) 사용방법을 알면 나머지도 동일한 패턴으로 사용 하면 됩니다.

* * * * * : 매일 매시간 매분 명령어 실행

*/10 * * * * : 매일 매시간 매10분마다(10,20,30,40,50,00) 명령어 실행

0-30/5 * * * * : 매일 매시간 0분에서 30분사이 5분마다 명령어 실행

1 * * * * : 매일 매시간 1분마다 명령어 실행

0-30 * * * * : 매일 매시간 0분부터 30분까지 매분 명령어 실행

1,5,7,9 * * * * : 매일 매시간 1분, 5분,7분, 9분 명령어 실행

이렇게 분을 사용하듯 나머지도 유추해서 사용하면 됩니다.

명령어 뒤에 /dev/null을 붙여서 사용하는걸 보았을 텐데 그 의미는

* * * * * /home/copycoding/test.sh > /dev/null 2>&1

/dev/null 은 저장하지 않고 삭제한다는 의미로 로그를 남기지 않겠다는 표시고

2는 표준에러를 > 리다이렉트 해서 &1 = 표준출력 한다는 것으로

2>&1 이란 stderr 도 표준 출력 즉 /dev/null로 보내란 뜻입니다.

결론은 에러가 나도 표시하지 말고 삭제해서 안보이게 하라.

에러내용을 파일로 저장하려면 /dev/null 위치에 /usr/log/error.log와 같이 저장하려는 파일명을 적어주면 됩니다.

* * * * * /home/copycoding/test.sh > /home/copycoding/log/test.log

3. URL 실행 방법

crontab으로 URL을 실행하려면 curl을 사용하면 됩니다.

* * * * * /usr/bin/curl http://127.0.0.1:8080/test.do

만약 GET 방식으로 parameter들이 붙아야한다면 뒤에있는 param이 잘릴 수 있으니 URL을 따옴표러 묶어주면 됩니다.

* * * * * /usr/bin/curl “http://127.0.0.1:8080/test.do?id=koi8&name=copycoding”

4 crontab 편집

실제 crontab을 작성하고 관리하는 명령어들 입니다. 콘솔에서 명령어를 입력해서 작업하면 됩니다.

편집 후에는 crontab을 재실행 해줍니다.

# service crond restart

crontab을 중지 하려면 다음 명령어를 사용합니다.

# service crond stop

crontab을 중지 후 사용 하려면 다음 명령어를 사용합니다.

# service crond start

실행할 명령어가 많다면 주석을 이용해 설명을 해야 하는데 이때는 맨 처음에 #을 붙여주면 됩니다.

 - copy coding -

스프링 부트에서 내장된 tomcat이 아닌 외부 톰캣이나 기타 WAS를 이용하여 서비스를 하려면 프로젝트를 war로 배포해야 합니다.  배포 방법은 간단 합니다.

오늘은 몇일 전에 설치한 JEUS에 배포를 해보려고 하는데 작업 순서는

1. build.gradle에 war 추가 및 내장 톰캣 종속 제거

2. Application의 SpringBootServletInitializer 상속 수정

3. WAR 생성

4. JEUS 배포

5. 배포 오류

이고 Jeus 설치는 https://copycoding.tistory.com/388 을 참고하면 됩니다.

1. build.gradle에 war 추가

먼저 Spring Boot에서 war를 생성할 수 있도록 build.gradle에 한줄 추가해 줍니다.

id 'war'

그리고 내장 tomcat이 WAR 추가되지 않도록 한줄 더 추가 합니다.

providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'

수정된 build.gradle 모습은

내장 tomcat을 제거하지 않으면 배포 중 오류가 발생하는 상황은 맨 끝에 소개합니다.

2. Application의 SpringBootServletInitializer 상속 수정

그리고 외부 WAS를 사용하기 위해 Context를 등록해야 하는데 예전에는 web.xml에 application context를 등록 했지만 servlet 3.0부터 SpringBootServletInitializer를 상속 받아 사용할 수 있도록 되었습니다.

기존 소스에 SpringBootServletInitializer 를 상속 받고 override를 해주면 됩니다.

configure가 보이는 군요.  클릭하고 [OK] 해서 추가해주고

return 값을 수정해 줍니다. 그냥 다 손으로 입력해도 됩니다.

3. WAR 생성

이제 Spring Boot에서 war를 생성 합니다.

Gradle Tasks에서 build 또는 war 를 더블 클릭해 줍니다.

Gradle Executions에 진행상황을 보여줍니다.  프로젝트를 빌드하다보면 test 소스 빌드에서 빨간색 오류가 나타나기도 하지만 무시해도 됩니다.  

Duration 숫자가 멈추고 완료되면 프로젝트의 build > libs 폴더에 가면 war 파일이 보입니다.

이제 Jeus를 실행해서 배포 준비를 합니다.

4. JEUS 배포

제우스 admin 화면 좌측 메뉴에서 [Servers]를 선택하여 서버들을 확인 합니다.

배포할 서버가 살아있는지 확인을 합니다. server1에 배포를 하려고 하는데 잘 살아있군요.

좌측 메뉴에서 [Applications] 메뉴를 클릭 합니다.

여기서 상단 회색 버튼 중 [deploy]를 클릭 하면 배포 설정 화면이 나옵니다.

id를 입력해 주고 path에서 [입력] 버튼을 클릭 하면 팝업 창이 하나 나오는데

deploy하려는 파일을 선택해 줍니다.  Type, Target Server 등은 위에 있는 이미지를 확인해서 설정 합니다. (지금보니 server1이 shutdown이네요. 실행전에 캡쳐한거라...)

아랫 부분에 있는 고급 선택사항에서는 Context Path만 입력 합니다.

여기에 입력하는 내용이 나중에 웹을 실행할때 영향을 주게 됩니다. 저는 프로젝트를 구분하려고/demo로 입력 했는데 그냥 /만 입력해도 됩니다.

이제 [확인] 버튼을 클릭하면 오류가 발생하던가 배포가 잘 되던가 하겠지요.

저는 배포가 잘 완료 되었습니다.

웹에서 접속을 해보려면 몇번 포트를 사용하고 있는지 확인을 해봐야하니 server1을 열어봅니다.

좌측 메뉴에서 [Servers]를 선택 하고

우축에서 server1을 클릭 하고

탭메뉴에서 [Resource]를 클릭해 보면 8088로 서비스가 되고 있군요.

몇일전에 글을 올린 STS4관련 프로젝트를 배포한것이니 http://localhost:8088/api/test하면 될것 같지만 배포할 때 [고급선택 사양]에서 /demo로 path를 잡았기 때문에 /demo를 추가해 주어야 합니다.

http://localhost:8088/demo/api/test

JEUS 8에도 배포가 잘 되었습니다.

5. 배포 오류

Spring Boot에서 war 를 만들어 배포할때 가장 많이 발생하는 오류입니다.

오류 로그를 보면

tomcat-embed-core는 1번에서 설명한것 처럼 꼭 제거를 해주어야 jeus에 배포시 오류가 발생하지 않습니다.  외부 Tomcat에서는 오류가 발생하지 않는데 jeus에서는 오류가 나옵니다.

- copy coding -