PWA

0. 앞선 글.

 

많은 이들이 모던 웹 개발하면 PWA와 SPA를 손꼽습니다. 실제로 제 글에서도 그렇게 소개를 했고요. 그렇게 알고 넘어갔는데 웹을 돌아다니던 중 다음과 같은 글을 발견했습니다.

 

https://itnext.io/the-state-of-progressive-web-apps-adoption-by-developers-8b119783d3b9

 

The State Of Progressive Web Apps Adoption By Developers

Are PWA preached or adopted by developers? Do they use these despite the lack of support on iOS? Here are some hints I gathered with polls…

itnext.io

 

눈이 갈 수밖에 없는 글이었습니다. PWA가 좋다곤 하는데 과연 얼마나 많은 개발자들이 PWA를 구현해서 사용하고 있을까요? 실제로 궁금하여 글을 읽고 내용을 공유하기 위해 한글 번역글을 남깁니다.

 

 

 

1. 프로그레시브 웹 앱의 채택 상태.

 

PWA가 개발자에 의해 전파되거나 선택되었나요? 그들은 iOS에서의 지원이 부족함에도 불구하고 PWA를 하나요? 지난 며칠간의 조사에서 수집한 몇 가지 힌트가 여기 있습니다.

 

Photo by YTCount on Unsplash

 

이번 주 "Apple vs Hey"이야기에 이어서 이러한 이슈에 대한 해결책으로 볼 수 있는 PWA가 대부분 개발자들에게 전파되었거나 실제로 이미 채택되었는지가 궁금했습니다. 

 

이런 나의 질문에 답하기 위해 트위터에서 설문조사를 실시하였고 이 새 블로그 게시물에 여러분과 공유하고 싶은 몇 가지 흥미로운 사실을 알게 되었습니다.

 

 

 

2. 한계점.

 

전 통계의 전문가도 아니고 조사 결과를 해석하는 전문가도 아닙니다. 또한 이 조사는 트위터에서 이루어졌으며 SNS를 통해 답변을 받았으므로 아마 충분하지 않을 수도 있습니다.

 

그러므로 이 글에서 읽은 내용을 당연하다고 생각하지는 말아주세요. 이글의 수치와 의견들을 더도 말고 덜도 말고 그저 힌트로만 봐주시기 바랍니다.

 

또한 저는 PWA의 열렬한 애호가입니다. 공정성을 유지하기 위해 노력할 수 있지만 동등한 경우에는 아마 PWA에 대해 부정적이기보단 긍정적일 겁니다.

 

 

 

3. 47%의 개발자는 PWA를 사용하지 않습니다.

 

나는 DEV.to의 PWA를 거의 매일 이용하고 있으며 트위터도 그러려고 하고 있습니다. 그러나 난 내가 내 핸드폰에서 매주 다른 것을 사용하고 있다고 생각하지 않았습니다. 그것이 처음 이 질문에 관심을 갖고 선택한 이유입니다.

 

놀랍게도 개발자의 47% 는 홈 화면에 설치된 PWA를 사용하고 있지 않습니다.

 

많은 개발자가 브라우저와 함께 PWA를 사용하고 있기 때문에 실제로는 숫자가 낮아야 한다고 생각하는 경향이 있지만 이 숫자는 꽤나 중요합니다.

 

물론 다음 장에서 볼 수 있듯이 이러한 낮은 비율의 주된 이유는 iOS에서 PWA에 대한 적절한 지원이 없기 때문입니다.

 

그럼에도 불구하고 이건 여전히 두 명의 개발자 중 거의 한 명이 PWA를 사용하지 않는다는 것을 의미하며 이는 개인적으로 모바일 기기에서 기술의 미래에 대해 약간의 걱정을 갖게 만듭니다. 응용프로그램을 프로그래밍하는 개발자가 응용프로그램을 사용하지 않거나 사용할 수 없다면 많은 사람들이 어떻게 받아들일까요?

 

반면에 긍정적인 점은 유리잔의 반은 비어있다기 보단 차 있다는 것입니다. 개발자 중 3명 중 1명꼴인 29% 는 매주 두 개 이상의 PWA를 사용합니다. 

 

https://bit.ly/3gbFUOI

 

 

또 흥미로운 점은 일부 개발자들은 PWA를 홈 화면에 고정해 두지 않을 채 데스크톱에서 여러 PWA를 사용하고 있다는 것입니다.

 

이것은 다음과 같은 생각으로 이어졌습니다: PWA의 미래가 실제로 모바일 폰이 첫 번째 장소가 아니라 데스크톱이었다면 어떨까요? 실제로 데스크톱이 모바일보다 먼저 인기를 얻으려면 어떻게 해야 할까요? 만약 이런 가정이 사실이면 구글의 크롬북은 적절했을까요? 아니면 구글은 크롬북을 믿고 PWA를 추진했을까요?

 

아마 너무 과한 해석과 과장이지만 난 정말로 이런 식으로 발전할지 안 할지를 알고 싶어 미래를 기다리고 있습니다. 

 

 

 

4. PWA를 사용하지 않는 사람들의 63%는 iOS를 사용합니다.

 

위에서 말했듯이 iOS의 부분적인 지원은 개발자가 PWA를 사용하지 않는 주된 이유입니다. PWA를 사용하지 않는 이들 중 63 %는 iPhone을 가지고 있습니다. 이는 모든 개발자의 30 %가 단순히 Apple에서 만든 전화를 가지고 있기 때문에 PWA를 사용하지 않는 것을 의미합니다.

 

https://bit.ly/31ufIuM

 

부분적인 지원보다 제가 받은 의견에 따르면 개발자들은 애플이 자동으로 "홈 화면에 추가하기"를 보여주지 않기 때문에 iOS에서 PWA 사용을 포기하는 것 같습니다. 애플은 Apple은 다른 브라우저를 통해 이러한 기능을 애플 기기에 구현하지 못하게 했습니다. 

 

나는 그것을 시도했고 맞았습니다. UX는 약간 실망스럽지만 iOS 홈 화면에 PWA를 설치할 수 있습니다. 관심이 있으시면 다음 트윗대로 진행하세요.

 

https://bit.ly/2VvkT9L

 

홈 화면에 웹 사이트를 추가할 수 있지만 적절한 PWA인 웹 사이트만 독립 실행형 앱으로 작동합니다. 정확한 피드백에 대해 Julio에게 감사드립니다.

 

나는 안드로이드에서 Firefox 모바일의 "홈 화면에 추가"UX를 시도해 보았습니다. 믿거나 말거나 그것이 실제로 최고라고 생각합니다. 크롬은 훌륭하지만 파이어 폭스는 나의 손을 이끌리게 했으며 "이봐 David 내가 여기 PWA를 네 폰에 올바르게 추가하는 방법을 보여줄게"라고 말하는듯한 느낌이 들었습니다.

 

파이어폭스의 디자이너가 이 글을 읽게 될지 모르겠지만 축하합니다. 대단한 일입니다!

 

https://bit.ly/2Vzl4Bc

 

5. 개발자의 8%가 Google Play의 앱을 좋아합니다.

 

모든 개발자의 30%가 iPhone으로 인해 PWA를 사용하지 않는다 하더라도 PWA 친화적인 안드로이드 폰을 소유하고 있는 17%의 개발자들 역시 PWA를 사용하지 않습니다. 이것이 마지막 설문조사를 실시한 이유입니다. 왜일까요?

 

가능한 해결책에 대해 생각하는데 시간이 걸렸으며 내 제안으로 설문 조사를 너무 편향적으로 만들지 않을까 걱정했습니다. 아마 오픈된 질문을 하는 게 더 나을 겁니다.

 

안드로이드에서 PWA를 사용하지 않는 전체의 7%에서 대부분의 개발자인 44%는 스토어나 Google Play의 UX나 디자인이 좋다고 느끼기 때문에 PWA를 사용하지 않습니다. 

 

솔직히 말해서 나는 이러한 사실을 해석하는 방법을 모르겠습니다. 내게도 같은 이유로 나쁜 기본 앱만큼 못생기고 성능이 좋지 않은 웹 애플리케이션이 있을 수도 있습니다. 나는 그게 개념과 실행에 관한 것이라고 생각합니다. 기술에 관계없이 나쁘게 구현되거나 디자인된 경우 결국에는 놀랍지 않을 것입니다.

 

https://bit.ly/2ZqJDRI

 

주목할만한 점: PWA가 저가형 장치에 가장 적합하다고 언급한 피드백에 따라 KaiOS가 PWA를 지원하는지 궁금합니다. 맞춰볼까요? KaiOS은 PWA를 지원할 뿐만 아니라 이를 스토어에 게시할 수도 있습니다.

 

 

 

6. 결론

 

PWA의 미래는 데스크톱일까요? 아니면 KaiOS 매장과 Google Play에 모두 게시할 수 있는 모바일 기기가 미래가 될까요? 아니면 언젠가 EU가 애플을 PWA 친화적으로 만들까요? 그 누가 알겠습니까...

 

그러나 확실히 나는 몇 가지 흥미로운 힌트를 배웠으며 앞으로도 PWA를 믿습니다.

 

또한, 저는 2021년 6월 달력에 이런 조사를 다시 실시하기 위해 미리 알림을 추가했습니다. 내년에는 이 주제가 어떻게 진화했는지 살펴보겠습니다.

 

당신의 의견과 피드백을 기다리겠습니다. 

 

David

 

 

 

7. 맺음글

 

글이 오롯이 PWA의 채택률에 집중되어 있지 않다는 생각이 들긴 하지만 설문으로 얻어진 수치만을 보더라도 충분의 의미가 있다고 생각합니다.

 

모두가 모던 웹의 SPA와 PWA를 말하고 있지만 실제로 아직 많은 사람이 쓰고 있진 않단 걸 알 수 있는 글이었습니다. 

 

David의 말대로 내년에도 이와 같은 조사가 수행된다면 어떻게 바뀔지 궁금합니다. 

 

 

 

 

 

 

 

 

Cloud환경이 아닌 Self-managed로 Jira를 설치하는 방법에 대해 알아봅니다. 이 글에선 Ubuntu server 20.04 버전에 Jiral를 설치해 보도록 하겠습니다.

 

 

 

0. 사전 준비.

 

Ubuntu server 20.04 환경을 미리 준비합니다.

 

 

 

1. Jira Software 다운로드.

 

여기에서 Jira Software를 다운로드합니다. 서비스될 운영체제에 맞게 다운로드해주시면 되며 이 글에선 Ubuntu server에 설치할 것이므로 Linux 64 bit를 선택해 다운로드해 줍니다.

 

 

다운로드가 끝나면 파일을 서버로 옮겨주세요.

 

 

 

2. Jira 설치.

 

서버로 접속 해 설치 파일을 복사한 경로로 이동합니다.

 

 

다음 명령어로 복사한 설치 파일에 권한을 부여합니다.

 

$ sudo chmod a+x atlassian-jira-software-8.10.0-x64.bin

 

실행 권한이 부여되면 다음 명령어로 설치 파일을 실행시켜줍니다.

 

$ sudo ./atlassian-jira-software-8.10.0-x64.bin

 

 

Jira는 OpenJDK를 필요로 합니다. Y를 입력해 Jira를 설치하면서 OpenJDK가 같이 설치되도록 합니다.

 

 

설치 준비 과정을 잠시 기다린 후 위와 같은 메시지가 나오면 엔터를 눌러줍니다.

 

 

설치 옵션을 골라줍니다. 첫 설치 환경이고  잘 모르겠으면 기본 설정을 사용해 줍시다. 1을 입력하세요.

 

 

앞서 선택한 옵션에 따라 Jira가 설치될 때 참고할 설정입니다. 확인 후 엔터를 눌러주세요.

 

 

설치가 끝나면 Jira를 바로 실행할 건지 묻습니다. 엔터를 눌러 바로 실행시키도록 합니다.

 

 

설치가 완료되었습니다. 이제 나머지 구성을 진행해 봅시다.

 

 

 

3. MySQL 설치.

 

제가 가장 삽질한 부분입니다. 2020.06.25 현재 Ubuntu Server 20.04로 mysql-server를 설치하면 8.0.20 버전이 설치됩니다. 별도 커넥터도 설치하고 구성 파일도 변경해봤으나 이 버전은 Jira에서 자꾸 에러 메시지를 던집니다.

 

공식적인 답변을 확인한 결과 MySQL8의 지원은 Jira 이슈에 공식적으로 등록된 상태이며 6일 전인 2020.06.19에 개발이 시작되었다고 댓글이 달렸습니다.

 

https://jira.atlassian.com/browse/JRASERVER-67359

 

[JRASERVER-67359] Add support for Jira to use MySQL 8 - Create and track feature requests for Atlassian products.

Problem Definition Current versions of Jira support several database types/versions, however Jira does not currently support MySQL 8.0 per the Supported platforms - Atlassian Documentation. For MySQL, only 5.5 -> 5.7 versions are currently supported. It wo

jira.atlassian.com

 

결론적으로 이 글이 작성되는 시점에선 MySQL 8 버전은 지원하고 있지 않으며 적절한 드라이버를 사용해도 Jira는 오류를 반환합니다. 따라서 우리는 5.7 버전의 MySQL을 설치해 보도록 하겠습니다.

 

먼저 현재 리포지토리에 MySQL 5.7 버전이 있나 확인해 봅시다.

 

$ sudo apt-cache mysql-server

 

 

슬프게도 등록되어 있지 않습니다. 그 말은 우리가 별도로 다운로드 해와야 한다는 뜻이죠. 다음 작업을 차근차근 따라 해 봅시다. 먼저 deb 파일을 받습니다.

 

$ sudo wget https://dev.mysql.com/get/mysql-apt-config_0.8.12-1_all.deb 

 

 

받은 deb 파일을 확인하고 실행시킵니다.

 

$ sudo dpkg -i mysql-apt-config_0.8.12-1_all.deb

 

 

위의 명령어를 실행하면 MySQL에 대한 apt 설정을 할 수 있는 화면이 보입니다.

 

 

Ubuntu bionic을 선택합니다.

 

 

MySQL Server & Cluster를 선택합니다.

 

 

MySQL 5.7을 선택합니다.

 

 

구성이 MySQL 5.7로 바뀐 것을 확인한 뒤 OK를 선택합니다. 이후 업데이트 후 다시 MySQL을 검색해 봅니다.

 

$ sudo apt-get update

$ sudo apt-cache policy mysql-server

 

 

이제 5.7 버전이 보입니다. 이 버전을 설치합시다. mysql-client를 설치하지 않고 mysql-community-server를 설치하면 client를 먼저 설치하라는 메시지와 함께 server 설치가 실패합니다. client를 먼저 설치해줍시다.

 

$ sudo apt install -f mysql-client=5.7.30-1ubuntu18.04

$ sudo apt install -f mysql-community-server=5.7.30-1ubuntu18.04

 

server 설치를 수행하게 되면 다음과 같은 화면에 보입니다.

 

 

루트 유저의 비밀 번호를 입력합니다. 설치가 완료되면 다음 명령어로 제대로 5.7 버전이 설치되었는지 확인합니다.

 

$ sudo mysql --version

 

 

 

 

3. MySQL DB 생성.

 

이제 MySQL에 Jira가 사용할 DB와 유저를 생성해 봅시다.

 

다음 명령어로 MySQL에 접속합니다.

 

$ sudo mysql -u root -p

 

 

먼저 Jira를 위한 DB를 생성합니다. 다음 쿼리를 실행시켜 주세요.

 

> CREATE DATABASE jira CHARACTER SET utf8mb4;

 

 

이제 이 DB에 유저를 생성한 뒤 권한을 부여해 줍니다.

 

> CREATE USER 'jira'@'localhost' IDENTIFIED BY 'P@SSWORD';

> GRANT ALL PRIVILEGES ON jira.* TO 'jira'@'localhost';

> FLUSH PRIVILEGES;

 

 

이제 새로 생성한 유저로 다시 mysql에 접속해 확인해 보도록 합니다.

 

$ sudo mysql -u jira -p

> show databases;

 

 

로그인도 정상적으로 되고 DB도 생성된 것을 확인하였습니다.

 

 

 

4. JDBC 설치 및 MySQL 설정 변경.

 

다음으로 Jira가 MySQL에 붙을 수 있도록  MySQL JDBC 드라이버를 설치해야 합니다. 우리는 5.7.30 버전의 MySQL을 설치했으므로 이 버전에 맞는 커넥터를 다운로드하여야 합니다. 여기에서 커넥터를 다운로드하도록 합니다. 이 글을 따라 하셨다면 다음과 같이 설정 후 다운로드하시면 됩니다.

 

 

어떤 걸 다운해도 상관없습니다. 어차피 압축을 풀고 그 내부의 파일을 사용해야 합니다. 다운로드한 파일을 압축 해제 한 뒤 폴더 내에 있는 "mysql-connector-java-5.1.49-bin.jar" 파일만 서버로 옮겨줍니다.

 

이제 이 jar 파일을 jira 설치 경로 내의 lib 폴더로 이동시켜 줍니다.

 

$ ls

$ sudo cp mysql-connector-java-5.1.49-bin.jar /opt/atlassian/jira/lib/

$ ls /opt/atlassian/jira/lib

 

 

그 후 해당 파일에 읽기 권한을 부여합니다.

 

$ sudo chmod 755 /opt/atlassian/jira/lib/mysql-connector-java-5.1.49-bin.jar

 

추가한 커넥터를 사용할 수 있도록 jira를 재시작합니다. jira start/stop 명령어는 jira를 설치한 방식에 따라 달라질 수 있습니다. 아래의 명령어는 linux installer를 통해 설치했을 때 사용할 수 있는 명령어임을 참고해 주세요.

 

$ sudo /etc/init.d/jira stop

$ sudo /etc/init.d/jira start

 

다음은 MySQL의 설정 파일을 변경해 줄 차례입니다. MySQL의 기본 설정값을 사용하게 되면 Jira가 신나게 경고 메시지를 띄워대니 그냥 Jira 설정에 맞춰서 변경합니다.

 

MySQL의 설정 파일은 /etc/mysq/my.cnf입니다. 우선 이 설정 파일의 백업본을 생성해 줍니다.

 

$ cd /etc/mysql

$ sudo cp my.cnf my.cnf.bak

 

 

그 후 my.cnf에 다음 설정을 추가합니다.

 

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_bin
default-storage-engine=INNODB
max_allowed_packet=256M
innodb_log_file_size=2GB
transaction-isolation=READ-COMMITTED
binlog_format=row

 

$ sudo vi my.cnf

 

 

** 만약 my.cnf에 "sql_mode = NO_AUTO_VALUE_ON_ZERO"가 있다면 이 옵션은 삭제해 주세요.

 

설정 파일을 변경하였으면 MySQL을 재시작합니다.

 

$ sudo service mysql restart

 

 

 

5. Jira 초기 설정 및 라이선스 활성화.

 

Jira가 설치된 서버에 8080 포트로 접근하면 다음과 같은 Jira 초기 설정 화면을 확인할 수 있습니다.

 

 

** 우측 상단의 "언어"를 클릭하면 한국어 옵션을 사용할 수 있습니다.

 

"사용자를 위해 설정하십시오."옵션은 별다른 추가 설정 없이 Trial 라이선스로 사용해 볼 수 있도록 해주는 옵션입니다. 이 옵션은 별도의 DB를 사용하지 않고 내장 DB를 사용하며 Atlassian의 계정과 연동해 알아서 설정을 구성해주고 Trial 라이선스를 발급받을 수 있는 화면으로 이동해 바로 라이선스 발급 절차를 진행할 수 있도록 해줍니다.

 

사전 준비사항에 언급한 대로 이 글에선 MySQL을 사용해 구성해 보도록 하겠습니다. "직접 설정하겠습니다"를 선택해주세요.

 

아래와 같이 설정한 DB 및 계정 정보를 입력한 후 테스트 연결 버튼을 클릭해 봅시다.

 

 

 

버튼을 클릭했을 때 아래와 같은 메시지가 보이면 연결에 성공한 것입니다.

 

 

** 만약 드라이버를 못 찾는다면 커넥터를 다시 한번 확인해 주시고 권한을 수정했는지 확인해 주시기 바랍니다.

** 만약 MySQL 5.7+ 설정에 관한 오류가 생기면 my.cnf 파일을 다시 확인해 주시기 바랍니다.

** 위의 두 과정 모두 jira 및 mysql의 재시작이 필요합니다.

 

이제 Jira가 구성될 때까지 느긋하게 기다려주세요.

 

 

왜 다시 영어로 돌아간 건지는 모르겠지만 구성이 완료되면 위와 같은 화면이 보입니다.

 

Application Title은 말 그대로 Jira의 타이틀입니다. 원하는 값으로 설정해 주세요.

Mode는 유저 생성에 관련된 설정값입니다. Private로 선택하면 회원가입이 막히고 Admin이 직접 추가한 유저만 사용할 수 있습니다.

BaseURL은 jira가 서비스될 URL을 입력해 줍니다.

 

 

이제 라이선스 키를 입력해 줄 차례입니다. 여기로 이동해 jira를 구입한 계정으로 로그인 한 뒤 라이선스 정보를 확인합니다.

 

라이선스를 클릭하면 오른쪽에 "License Key View License"와 같은 항목이 있습니다. "View License"를 선택해주세요.

 

 

위에 적혀있는 서버 ID를 입력한 후 Save를 클릭합니다. 그러면 "View License"에 생성된 라이선스 코드가 보이게 됩니다. 이 값을 jira의 "Your License Key"에 붙여 넣어 주고 Next 버튼을 클릭합니다.

 

 

이제 관리자 계정을 생성해 줄 차례입니다. 원하는 대로 생성해 주세요.

 

 

다음은 이메일 알림 관련 설정입니다. 이 내용은 추후 별도의 포스팅으로 다루겠습니다. Later를 선택한 후 Finish 버튼을 클릭합니다.

 

잠시 기다리면 구성이 끝나고 Jira가 시작됩니다. 사용할 언어를 다시 한국어로 변경합니다. 마지막으로 아바타 설정을 마치면 이제 Jira를 사용할 수 있습니다!

 

 

이제 "샘플 프로젝트 생성"을 선택해서 미리 잘 짜여 있는 예시를 볼 수도 있고 "새 프로젝트 만들기"를 선택해서 바로 자신만의 프로젝트를 구성할 수도 있습니다.

 

 

 

 

 

 

 

Ubuntu server 20.04에 Redmine을 설치하는 법에 대해 알아봅니다.

 

 

 

0. 사전 준비.

 

우분투 서버를 미리 설치해 둡니다. 우분투 서버에 접속 해 apt-get update를 진행해 주세요.

 

 

 

1. MariaDB 설치 및 Database 구성.

 

Redmine은 MariaDB를 사용합니다. Redmine 설치에 앞서 MariaDB를 설치해 줍시다.

 

$ sudo apt-get install mariadb-server

 

MariaDB가 설치되면 이제 Database를 생성해줍시다.

 

$ sudo mysql -u root -p

> CREATE DATABASE redmine CHARACTER SET utf8mb4;

 

 

DB 생성 후 redmine DB에 유저를 생성한 뒤 권한을 부여해 줍니다.

 

> GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost' IDENTIFIED BY 'P@SSWORD';

> FLUSH PRIVILEGES;

 

 

생성한 유저로 로그인해서 DB가 제대로 생성되었는지 확인합니다.

 

$ mysql -u redmine -p

> SHOW DATABASES;

 

 

 

 

2, Apache 설치.

 

Redmine을 서비스하기 위해 필요한 제품을 설치합니다.

 

$ sudo apt-get install apache2 libapache2-mod-passenger

 

 

 

3. Redmine 설치.

 

이제 Redmine을 설치합니다.

 

$ sudo apt-get install redmine redmine-mysql

 

설치를 진행하다 보면 "Configuring redmine" 화면이 나타납니다. 설정을 진행해 줍시다.

 

OK를 선택합니다.

 

Yes를 선택합니다.

 

 

관리자 암호를 입력해줍니다.

 

 

다시 한번 입력하도록 합니다. 이후 설치가 완료되면 다음 명령어를 통해 bundler를 설치합니다.

 

$ sudo gem update

$ sudo gem install bundler

 

 

설치 완료 후 Apache passenger 모듈의 설정 파일을 다음과 같이 수정합니다.

 

$ sudo vi /etc/apache2/mods-available/passenger.conf

 

<IfModule mod_passenger.c>
  PassengerDefaultUser www-data
  PassengerRoot /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini
  PassengerDefaultRuby /usr/bin/ruby
</IfModule>

 

 

이제 www에 Redmine의 심볼릭 링크를 생성해 줍니다.

 

$ sudo ln -s /usr/share/redmine/public /var/www/html/redmine

 

 

 

4. Apache2에 Redmine 구성파일 생성.

 

/etc/apache2/sites-available 폴더에 Redmine.conf 파일을 생성 한 뒤 다음과 같이 작성합니다.

 

$ sudo vi /etc/apache2/sites-available/redmine.conf

<VirtualHost *:80>
  ServerAdmin admin@example.com
  DocumentRoot /var/www/html/redmine
  ServerName projects.example.com
  ServerAlias www.projects.example.com
  <Directory /var/www/html/redmine>
    RailsBaseURI /redmine
    PassengerResolveSymlinksInDocumentRoot on
  </Directory>

  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

 

 

만약 도메인 이름을 아직 정하지 못했거나 없다면 위의 방식 대신 아래의 방식을 사용해 IP주소를 통해 Redmine에 액세스 할 수 있습니다.

 

위와는 다른 000-default.conf 파일을 수정합니다.

 

$ sudo vi /etc/apache2/sites-available/000-default.conf

 

<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  DocumentRoot /var/www/html/redmine
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  <Directory /var/www/html/redmine>
    RailsBaseURI /redmine
    PassengerResolveSymlinksInDocumentRoot on
  </Directory>
</VirtualHost>

 

 

이제 Apache의 www-data 사용자가 액세스 할 수 있도록 Gemfile.lock을 생성하고 권한을 부여해 줍니다.

 

$ sudo touch /usr/share/redmine/Gemfile.lock

$ sudo chown www-data:www-data /usr/share/redmine/Gemfile.lock

 

구성 파일대로 Redmine을 활성화합니다.

 

$ sudo service apache2 restart

 

이제 호스트나 IP주소를 입력해 웹사이트로 이동해 봅시다.

 

 

정상적으로 Redmine이 활성화된 것을 확인할 수 있습니다. 이제 Redmine에서 프로젝트에 대한 설정을 한 뒤 사용하시면 됩니다.

 

기본 Admin계정 및 암호는 admin/admin입니다.

 

 

 

 

 

 

앞선 글에서 Express를 이용해 클러스터를 구성해 여러 워커를 가진 서버를 띄워보았습니다. 이번에는 제작한 웹 서버를 이용해 이중화 구성을 한 뒤 nginx를 이용해 로드밸런서를 만들어 그럴듯한 운영 환경을 구성해 보도록 하겠습니다.

 

 

 

0. 사전 준비.

 

이 글에서는 앞선 글에서 작성한 웹 서버를 사용합니다. 이전 글을 참고해 웹 서버를 준비해 주세요.

Nginx를 사용할 예정이니 미리 서버를 다운로드하여 주셔도 좋습니다. 단, Docker를 이용하실 분은 별도의 Nginx를 준비하지 않으셔도 됩니다.

모든 결과물을 한번에 배포하기 위해 docker-compose를 사용할 예정입니다. docker-compose를 준비해 주세요.

 

 

 

1. Nginx를 이용한 이중화 구성.

 

이제 우리가 만든 서버는 여러 개의 워커를 갖고 도커 위에서 동작합니다. 이제 안정성을 위해 두 개의 서버를 올려두고 그 앞에 Nginx를 둬서 로드밸런서의 역할을 하도록 합시다.

 

우리가 할 일은 단지 nginx의 config파일을 추가하는것 뿐 입니다. 아무런 추가 작업을 진행하지 않은 채 설정 파일을 추가해 주는 것만으로도 로드밸런서를 구성할 수 있습니다.

 

새로운 폴더인 my-nginx를 생성하고 그 안에 nginx 폴더를 만들어줍니다. 그리고 그 안에 nginx.conf 파일을 작성합니다.

 

#./nginx/nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

 

사실 위의 설정파일은 nginx를 설치하면 가장 기본으로 들어가 있는 값입니다. 스킵하셔도 무방합니다만 나중에 수정된 값을 사용할 수 있으므로 넣어주었습니다.

 

설정 파일을 살펴봅시다. nginx.conf의 맨 아래 include를 보세요. 이 include가 의미하는 바는 /etc/nginx/conf.d폴더 내의 모든 conf파일을 가져와 http 아래에 두겠다는 뜻입니다.

 

따라서 우리가 다음에 작성할 설정 파일이 바로 아래 추가될 것이란 의미가 됩니다. 이 외에도 nginx의 default 페이지가 담긴 default.conf도 추가될 것입니다. 

 

 

그다음으로nginx 안에 conf.d 폴더를 생성 한 뒤 my-react-lb.conf파일을 작성합니다.

 

# ./nginx/conf.d/my-react-lb.conf

upstream my-react {
    #least_conn;
    #ip_hash;
    server localhost:3000 weight=10 max_fails=3 fail_timeout=10s;
    server localhost:3001 weight=10 max_fails=3 fail_timeout=10s;
}    
server {
    listen                8080;
    server_name  localhost;
    location / {
        proxy_pass http://my-react;
    }
}

 

이 파일의 폴더 경로도 실제 리눅스 시스템에서 nginx가 위치하는 폴더의 경로를 맞추기 위함이므로 임의의 폴더에 작성하셔도 됩니다.

 

server항목을 먼저 봅시다. 이 서버는 8080 포트에서 동작하고 리버스 프록시로 동직 합니다. 즉, localhost:8080으로 들어오면 내부적으로 my-react로 연결시킨다는 뜻입니다. 이때 연결하는 my-react가 위에서 정의한 upstream입니다.

 

upstream 내부에 두 개의 서버가 정의되어 있습니다. 유저가 들어올 때마다 번갈아 가면서 3000, 3001 포트에 올라간 서버가 접속을 수용할 겁니다. 정리하자면 localhost:8080으로 접속하게 되면 내부적으로 로드밸런싱을 거쳐 localhost:3000, locahost:3001로 이동하게 된다는 겁니다.

 

주석 처리한 least_conn은 번갈아 가면서 수용하는 게 아닌 현재 접속이 가장 적은 곳에 우선 접속할 수 있도록 하는 기능이며 ip_hash는 접속한 사용자의 ip를 해싱해서 같은 사용자는 같은 서버로 접속할 수 있게 해 세션 문제 등을 해결할 수 있도록 하는 기능입니다.

 

따라서 메인 서버에 위의 설정 파일을 갖는 nginx를 설치한 뒤 Docker로 3000, 3001 포트에 앞서 작성한 웹 서버를 두대 올려 둔 후 localhost:8080으로 접속하면 정상적으로 로드밸런싱이 동작할 겁니다. 

 

 

 

2. Docker compose를 이용해 한번에 배포하기.

 

 

사실 위와 같이 배포하기 위해서는 서버에 nginx를 직접 설치해야 하며 그 서버에서 Docker가 동작 해 웹서버가 돌아야 합니다. 즉, nginx가 돌아가는 localhost에 웹서버가 동작해야 한다는 뜻입니다.

 

서버에 접속해 nginx를 설치하고 conf 파일을 수정해준 뒤 그 서버에 docker를 설치하고 docker 명령어로 두 개의 웹서버를 실행시키는 과정이 필요하게 됩니다. 이것만 해도 귀찮아지기 시작합니다. 게다가 수작업이 들어가는 만큼 오류의 가능성도 높아집니다.

 

이제 좀 더 편하게 위 과정을 다음과 같이 변경할 겁니다.

  1. Nginx를 직접 설치하지 않고 Docker Image로 빌드 해 Docker 명령어로 배포한다
  2. 명령어를 미리 작성해 둬 한번에 여러 이미지를 배포한다.

그러기 위해선 docker-compose와 nginx를 docker image로 빌드하는 작업이 필요합니다. 우선 nginx를 docker image로 빌드하기 위해 Dockerfile을 작성합니다.

 

# ./Dockerfile

FROM nginx:stable

COPY ./nginx/nginx.conf /etc/nginx/nginx.conf
COPY ./nginx/conf.d/my-react-lb.conf /etc/nginx/conf.d/my-react-lb.conf

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

 

매우 간단합니다. nginx 안정화 버전을 받아 우리가 작성한 conf파일을 복사 한 뒤 실행합니다. 이제 다음 명령어로 docker image를 빌드합니다.

 

$ docker build . -t my-nginx:0.0.1

 

그리고 빌드한 이미지를 실행해 봅시다. 

 

$ docker run -itd -p 3000:3000 my-react:0.0.1

$ docker run -itd -p 3001:3000 my-react:0.0.1

$ docker run -itd -p 8080:8080 my-nginx:0.0.1

 

localhost:8080으로 이동하면 어떻게 될까요?

 

 

에러가 보이는 이유에 대해 생각해 봅시다. 우리는 nginx를 도커로 돌렸으며 my-react-lb.conf의 upstream에 server로 localhost:3000와 localhost:3001을 등록했습니다. 과연 nginx 컨테이너 내에서 이 두 서버에 접속할 수 있을까요?

 

궁금하신 분은 다음 명령어로 한번 테스트해보시기 바랍니다.

 

$ docker exec -u 0 -it (my-nginx 컨테이너 ID) bash

$ apt-get update

$ apt-get intall telnet

$ telnet localhost 3000

 

당연히 독립된 네트워크 이므로 접속을 할 수 없습니다.

 

 

그러므로 우리는 Docker compose를 이용해야 합니다. Docker compose는 같이 배포되는 컨테이너끼리 미리 정의된 이름으로 접속이 가능합니다. 마치 도메인 네임처럼 말입니다.

 

최상위 폴더로 이동해 docker-compose.yml 파일을 생성합니다 저 같은 경우엔 my-react와 my-nginx를 포함하고 있는 폴더에 작성하였습니다.

 

 

그리고 docker-compose.yml을 다음과 같이 작성해 줍니다.

 

# docker-compose.yml

version: "3"
services:
    my-react-A:
        image: my-react:0.0.1
        ports:
            - "3000:3000"
    my-react-B:
        image: my-react:0.0.1
        ports:
            - "3001:3000"
    nginx:
        image: my-nginx:0.0.1
        ports:
            - "8080:8080"

 

여기서 서비스 항목을 봅시다. 우리는 my-react-A, my-react-B, nginx 이렇게 총 세 개의 컨테이너를 생성하도록 작성하였습니다. 당연히 이름은 변경해도 됩니다. 서비스 내의 image는 도커 이미지를 의미합니다. ports는 docker run의 -p 옵션과 동일합니다. 

 

이런 식으로 docker-compose를 구성하게 되면 위의 세 컨테이너 간에는 서비스에 작성한 이름으로 서로 접근이 가능해집니다. 따라서 우리의 my-react-lb.conf가 바뀌어야 함을 의미하죠.

 

# ./nginx/conf.d/my-react-lb.conf

upstream my-react {
    #least_conn;
    #ip_hash;
    server my-react-A:3000 weight=10 max_fails=3 fail_timeout=10s;
    server my-react-B:3000 weight=10 max_fails=3 fail_timeout=10s;
}    
server {
    listen                8080;
    server_name  localhost;
    location / {
        proxy_pass http://my-react;
    }
}

 

그리고 다시 도커 이미지를 빌드해 줍니다.

 

$ docker build ./my-nginx -t my-nginx:0.0.2

 

잊지 마세요. 태그에 버전을 0.0.2로 변경하였으므로 당연히 docker-compose를 변경해야 합니다. 이제 docker-compose를 통해 컨테이너를 올려보겠습니다.

 

$ docker-compoase up -d

 

우리가 작성한 docker-compomse파일 대로 컨테이너가 실행되었습니다. 이제 localhost:8080으로 이동해 보세요. react페이지가 보이시나요? 

 

그렇다면 우리가 어떤 서버로 접속했는지 알아보기 위해 localhost:8080/where로 이동해 봅시다.

 

 

위와 같이 접속할 때마다 서버 정보가 변경되는 것을 확인할 수 있습니다. 실제 운영환경에선 이렇게 하면 서버가 바뀌며 세션정보가 유실되므로 앞서 설명한 ip_hash와 least_conn옵션을 켜고 서버를 배포해야 합니다.

 

 

 

 

 

 

 

1. CString to const char*

 

CString strText = _T("myStirng");
const char* ccText;
ccText = (CStringA)strText;

 

 

 

2. const char* to CString

const char* ccText = "myString";
CString strText;
ccText = (CString)strText;

 

 

 

 

 

Jenkins에서 빌드 결과를 이메일로 알려주는 방법에 대해 알아봅니다.

 

 

 

0. 사전 준비

 

다음 글을 참고하여 사전 준비를 합니다.

 

 

 

1. 플러그인 준비.

 

이메일 알림에는 사실 별도의 플러그인 없이 Jenkins > 환경 설정에 들어가서 아래로 쭉 내리면 "Email로 알려줌"이라는 메뉴가 있습니다.

 

 

이 메뉴는 별도의 플러그인을 설치 하지 않아도 기본적으로 Jenkins에서 제공해 주는 것으로 보입니다. 이 글에선 이 기능을 이용하지 않습니다.

 

사실 별도의 플러그인을 설치하지 않아도 Jenkins 설치시 추천 설치를 했다면 "Email Extension Plugin"이 같이 설치됐을 것입니다.

 

 

플러그인 리스트에서 이 플러그인이 없다면 설치해 줍니다. 그리고 다시 Jenkins > 환경설정으로 이동 한 뒤 "Email로 알려줌" 바로 위에 보면 "Extended E-mail Notification"메뉴가 있을 겁니다.

 

 

잠깐 봐도 기본 기능보단 더 많은 기능을 제공할 것처럼 보입니다. 이제 이 빈칸을 하나씩 채워봅시다.

 

 

 

2. 플러그인 설정.

 

개인이 사용하는 메일서버가 있으면 최선이겠지만 그런 경우는 드물다 생각하므로 일단 gmail을 이용해 보도록 하겠습니다. 입력 전에 고급 버튼을 눌러 숨겨진 입력창을 펼쳐주세요.

 

  • SMTP Server: SMTP 서버 주소를 입력합니다. Gmail을 사용하는 경우 "smtp.gmail.com"을 입력하시면 됩니다.
  • Use SMTP Authentication: 인증 여부를 선택합니다. 체크해 줍시다.
  • User Name: 메일 인증에 사용될 유저입니다. Gmail 로그인 계정을 입력합니다.
  • Password: 메일 인증에 사용될 암호입니다. Gmail 로그인 계정의 암호를 입력합니다.
  • Use SSL: SSL 사용 여부를 체크해 줍니다. Gmail은 당연히 사용합니다.
  • SMTP Port: SMTP 서버의 포트입니다. SSL을 사용하는 경우는 465, 사용하지 않는 경우는 587을 기본 포트로 사용합니다.
  • Default Recipients: 메일을 송신할 대상을 정합니다. 공백이면 안되므로 수신 대상의 메일 주소를 적습니다.
  • Default Triggers: 언제 메일을 송신할지 결정합니다. 일단 테스트용으로 Always를 선택합니다.

모두 다 작성하면 대략 다음과 같이 될 겁니다.

 

 

 

 

3. 구글 보안 설정 변경.

 

구글 SMTP 서비스를 사용하기 위해선 구글 계정의 보안 설정을 변경해야 합니다. 먼저 구글 계정 > 보안 페이지로 이동합니다: https://myaccount.google.com/security

 

이 페이지에서 "보안 수준이 낮은 앱의 액세스"를 사용 설정으로 변경해주어야 합니다.

 

 

위의 메뉴에서 "액세스 사용 설정을 클릭합니다"

 

 

위와 같이 사용하도록 수정합니다.

 

 

 

4. 프로젝트 설정.

 

그다음으로 프로젝트에서 빌드가 끝나면 메일을 발송하도록 해야 합니다. 생성한 젠킨스 프로젝트로 이동해 구성 버튼을 눌러 빌드 후 조치로 이동합니다.

 

 

빌드 후 조치 추가에서 "Editable Email Notification"을 선택합니다.

 

 

설정에서 메일 내용을 변경할 수 있습니다. 우선 그대로 두고 "Attach Build Log" 항목만 수정합니다. 이제 메일을 발송할 준비가 모두 끝났습니다.

 

 

 

5. 빌드 및 알림 메일 확인.

 

그러면 빌드를 수행해 봅니다. 빌드가 수행된 후에 Console output으로 이동해 가장 마지막 로그를 확인해 봅니다.

 

Email was triggered for: Always
Sending email for trigger: Always
Sending email to: @gmail.com
Finished: SUCCESS

 

우리가 설정한 트리거 조건과 함께 어디로 메일을 보냈는지 로그가 찍혀있습니다. 이제 직접 메일로 들어가 알림을 확인해 봅시다.

 

 

위와 같이 안내 메시지와 빌드 로그, 빌드 결과 링크가 함께 메일로 보내진 것을 확인할 수 있습니다.

 

 

 

 

 

 

Jenkins로 NodeJS 프로젝트를 빌드해 봅니다.

 

 

 

0. 사전 준비

 

다음 글을 참고하여 빌드 준비를 합니다.

 

 

 

1. NodeJS 플러그인 설치.

 

NodeJS 프로젝트를 빌드하기 위해선 먼저 플러그인이 필요합니다. 

 

 

위의 그림과 같이 Jenkins > Plugin Manager > Nodejs를 검색해 플러그인을 설치합니다.

 

 

 

2. 빌드 툴 설정.

 

플러그인을 설치했으면 이제 빌드에 사용할 NodeJS 버전을 정의해야 합니다. Jenkins > Jenkins 관리 > Global Tool Configuration으로 이동합니다.

 

 

아래로 내려보시면 NodeJS 버전과 관련된 메뉴가 있습니다. Add NodeJS 버튼을 눌러 빌드에 사용할 NodeJS 버전을 정의해 주세요.

 

 

 

 

3. 프로젝트 구성 설정.

 

이제 위에서 설정한 NodeJS를 프로젝트에서 사용할 수 있습니다. JenkinsItem을 하나 생성합니다. 이 예시에서는 Freestyle project로 생성하였습니다. 프로젝트 생성이후 생성한 Item > 구성 > Build로 이동합니다.

 

 

Add build step > Execute NodeJS script 를 선택합니다.

 

 

NodeJS Installation에 사용할 NodeJS 버전을 선택합니다. 해당 리스트는 위의 Global Tool Configuration에서 설정한 NodeJS 버전 리스트가 나타납니다. 지금 바로 NodeJS Script는 사용하지 않겠습니다. 

 

 

NodeJS 버전을 선택한 뒤 Add build step > Execut shell을 선택합니다.

 

 

이제 NPM 빌드 관련 명령어를 입력해 줍니다.

cd /var/lib/jenkins/workspace/lb-4-docker/
npm install
npm run build

 

먼저 해당 프로젝트가 있는 폴더로 이동후 필요한 패키지를 설치합니다. 그 후 빌드를 수행하는 명령어입니다.

 

 

 

4. 빌드 수행.

 

빌드를 수행할 차례입니다. Jenkins 프로젝트로 이동 후 좌측의 Build Now를 눌러 빌드를 수행합니다.

 

 

정상적으로 빌드되었다면 푸른색 원이 보입니다. 좌측의 Console Output메뉴로 이동해 빌드 로그를 확인할 수 있습니다.

 

 

 

 

 

 

SSH를 이용해 Github의 프로젝트를 jenkins와 연동하는 방법에 대해 알아봅니다.

 

 

 

0. 사전 준비

 

다음 글을 참고해 Jenkins를 미리 준비합니다: 2020/01/17 - [Linux] - [Ubuntu] CI/CD를 위한 Jenkins 설치

 

 

 

1. 키파일 생성

 

Jenkins가 설치되어있는 서버에서 키 파일을 생성해야 합니다. 다음 명령어를 통해 키 파일을 생성합니다.

 

> ssh-keygen -t rsa -f smoh-jenkins

 

위 명령어를 실행하면 두 개의 파일이 생성됩니다. 

 

 

확장자가 없는 smoh-jenkins는 개인키 파일이고 확장자가 있는 smoh-jenkins.pub는 공개키 파일입니다.

 

 

 

 

2. Jenkins에 개인 키 등록.

 

먼저 Jenkins에 개인키를 등록합니다.

 

 

위의 그림과 같이 Jenkins > Credential > System > Global credential(unrestricted) 또는 자신이 생성한 시스템으로 이동해 Add credential을 클릭합니다.

 

종류는 SSH Username with private key를 선택합니다. ID, Desc, Username은 모두 Jenkins에서 사용되는 값이므로 임의의 값을 입력합니다. 

 

PrivateKey는 Enter directlt 라디오 버튼을 누른 뒤 생성한 개인키 파일 내부의 값을 모두 입력해 줍니다. 만약 키를 생성할 때 Passphrase를 입력했다면 Passphrase에 입력한 값을 넣어줍니다.

 

 

정상적으로 Jenkins에 새 Credential이 생성되었습니다.

 

 

 

3. Github Project에 공개키 등록.

 

이제 깃헙 프로젝트에 생성한 공개키를 등록할 차례입니다. 

 

 

위 그림과 같이 Github > Project > Settings > Deploy keys > Add deploy key를 클릭합니다.

 

Title은 임의로 명명합니다. Key에는 위에서 생성한. pub 확장자를 가진 공개키의 내용을 모두 입력합니다. Allow write access는 필요에 따라 체크합니다.

 

 

정상적으로 깃헙 프로젝트에 공개키가 등록된 것을 확인할 수 있습니다.

 

 

 

4. 소스 코드 관리 설정.

 

이제 젠킨스와 깃헙의 리포지토리를 연동해 보겠습니다. 젠킨스에 새로운 아이템을 생성해 구성 페이지에서 소스 코드 관리로 이동합니다. 그리고 평소대로 리포지토리 주소를 입력한 후 Credential에 우리가 생성한 Credential을 고릅니다.

 

 

유저 이름과 암호가 다르다는 에러가 발생하네요. 우리는 일반적인 깃헙 로그인 계정을 사용해 Credential을 생성하지 않고 키 파일로 생성했기 때문에 일반적인 HTTPS 방식을 사용할 수 없습니다.

 

깃헙 프로젝트로 이동해 Clone or download에서 Use SSH를 선택하면 나오는 주소를 확인합시다.

 

 

이 값을 다시 젠킨스의 Repository URL에 넣어보세요.

 

 

에러 없이 정상적으로 연동되는 것을 확인할 수 있습니다.

 

 

 

 

 

 

LDAP Account Manager를 설치하고 사용하는 방법에 대해 알아봅니다.

 

 

 

0. 사전 준비

 

다음 글을 참고해 LDAP를 미리 준비합니다: 2020/01/20 - [Linux] - [Ubuntu] LDAP: OpenLDAP 설치하기

 

 

 

1. LDAP Account Manager 설치.

 

저는 편의상 LDAP가 설치된 우분투 서버에 LAM을 설치하였습니다. 다음 명령어를 실행시켜 LAM을 설치합니다.

 

> sudo apt-get install ldap-account-manager

 

알아서 필요한 파일을 모두 설치해 줍니다. 하나의 명령어만 실행시키면 LAM의 설치가 모두 끝납니다!

 

 

 

2. LDAP Account Manager 설정.

 

설치가 완료되었으면 http://{Host or IP}/lam/ 로 이동합니다. 맨 위의 그림이 우리를 맞이할 겁니다. 가장 오른쪽 위의 "LAM Configuration"을 클릭합니다.

 

그러면 보이는 두개의 옵션 중 "Edit server profiles"를 선택합니다. 기본 비밀번호는 "lam"입니다.

 

 

먼저 서버 설정입니다. 서버정보를 입력하고 Tree suffix에는 기본 DN정보를 입력해 줍니다.

 

 

다음은 보안설정입니다. 유저 리스트에 LDAP 인증 공급자 계정 정보를 입력합니다. 

 

 

이제 기본 암호 대신 사용할 자신의 암호를 입력합니다. 그 뒤 어카운트 타입 탭으로 이동합니다.

 

 

유저와 그룹에 사용할 ou정보를 입력해 줍니다. 이제 저장한 후 메인 페이지에서 아까 변경한 암호를 입력한 후 로그인합니다.

 

 

 

3. LDAP Account Manager 사용

 

로그인하면 다음과 같은 화면을 볼 수 있습니다.

 

 

아까 우리가 설정한 어카운트 타입을 기억하시나요? 그때 우리는 "Users"와 "Groups"의 "ou"를 설정하였습니다. 그 탭이 여기 그대로 보이네요! 전 이미 LDAP를 만들고 테스트하였기에 "ou=users"가 이미 존재하며 그 ou 내애 있는 유저 리스트도 불러온 것을 확인할 수 있습니다. 

 

 

그에 반해 Groups에는 아직 우리가 정한 ou에 해당하는 유닛이 없어 에러가 발생하네요. NewGroup를 선택해 새로운 그룹을 만들어 봅시다.

 

 

아무런 설정을 하지 않고 단지 DefaultGroup라는 그룹을 생성합니다.

 

 

아무래도 ou값은 자동으로 생성해주질 않나 봅니다. 그럼 직접 생성해 보도록 합시다. 우측 상단의 TreeView를 클릭합시다.

 

 

여기선 우리의 LDAP의 현황을 트리 구조로 확인할 수 있으며 직접 추가할 수도 있습니다. 이제 필요한 ou를 생성합시다. Create new entry here를 누르세요.

우린 새로운 ou가 필요합니다. 따라서 탬플릿은 Generic: Organisational Unit를 선택하면 됩니다. 우린 위에서 Groups를 설정할 때 ou를 group로 했습니다. 따라서 여기에 group를 입력한 뒤 Create object를 눌러줍니다.

 

 

작성한 내용을 확인하시고 commit를 누르신 뒤 Group탭으로 이동해보세요. 

 

 

더 이상 에러 메시지가 보이지 않네요. 기본 그룹도 다시 한번 생성해 보도록 합시다.

 

 

새로운 그룹도 정상적으로 생성된 것을 확인할 수 있습니다.

 

 

 

 

 

 

우분투 서버 18.04.2에 Jira를 설치해 봅니다.

 

 

 

1. Jira SW Server 다운로드

 

공식 홈페이지로 이동해 JIRA SW Server 설치 파일을 다운로드합니다. 미리 준비한 우분투 서버로 설치 파일을 옮겨주세요.

 

우분투 서버에 FTP를 사용하는 방법은 다음 글을 참고해 주세요: 2020/01/14 - [Linux] - [Ubuntu] FTP: Filezilla 서버 설치하기

 

 

 

2. JIRA 설치.

 

먼저 디렉토리를 이동해 설치 파일이 있는 폴더로 이동합니다. 그 후 다음 명령어를 통해 설치 파일에 실행 권한을 부여합니다.

 

> sudo chmod a+x atlassian-jira-software-X.X.X-x64.bin

 

실행 권한을 부여했다면 다음 명령어로 실행파일을 실행시킵니다.

 

> sudo ./atlassian-jira-software-X.X.X-x64.bin

 

OpenJDK를 설치하라는 메시지와 함께 설치가 진행됩니다. 중간에 프롬프트로 설치 옵션을 묻는 절차가 있습니다.

 

 

1을 입력하고 설치를 계속해 줍니다. 설치가 완료되면 자동으로 실행시킬 건지 묻는 메시지와 함께 설치가 완료됩니다.

 

 

정상적으로 설치가 완료되었습니다.

 

 

 

3. JIRA 설정.

 

설치가 완료되었다면 http://Host:8080으로 이동해 봅시다. 사용자 언어는 우측 상단의 Language를 눌러서 한글로 변경할 수 있습니다.

 

 

자세한 설정은 추후에 다루기로 하고 우선 기본값으로 설정해 봅시다. "사용자를 위해 설정하십시오"를 누른 후 "MyAtlassian으로 계속"을 누릅니다.

 

Atlassian계정으로 로그인하면 라이선스를 선택하는 화면에 나옵니다. 제품당 90일의 무료 평가판이 제공되니 우선 써보고 라이선스를 구매하시면 됩니다. "Jira Software (Server)"를 선택한 후 평가판 라이선스를 등록합니다.

 

라이선스를 정상적으로 등록하면 이제 어드민 계정 설정 화면이 나옵니다.

 

 

관리자 계정 정보를 넣고 다음 버튼을 누릅니다. JIRA가 자동으로 설정 파일을 구성하고 설치합니다.

 

 

설치가 완료되면 위와 같은 화면이 보입니다. 이제 시작해봅시다를 클릭해 JIRA를 사용합니다. 계정에 대한 기본 설정을 한 뒤 테스트 프로젝트를 생성해 어떻게 사용되는지 사용 케이스를 확인해 봅시다.

 

 

정상적으로 JIRA가 동작함을 확인할 수 있습니다.

 

 

 

 

 

+ Recent posts