It's Myself

VMWare에서 만든 Workstation 제품을 매우 오랜기간 사용해왔다. 아마도 10버전 때부터 구매해서, 매 버전마다는 아니지만, 중간 중간 상위 버전을 구매했다. (매 버전마다 대략 10만원 정도 쓴듯...)
다양한 테스트나 좀 위험한 프로그램을 돌릴 때, 이용을 많이 해왔는데, 상당히 유용했다.
물론 라이선스 문제가 있는 다른 분들은 Oracle의 VMBox나, Windows 10 Pro나 Windows Server 쪽에 탑재된 Hyper-V 등을 이용하는 경우도 있지만, 나 같은 경우 개발 PC에서 즉시 응답도 되고, 성능적인 하락 없이 충분히 동작하는 제품은 VMWare의 Workstation이 최고 였던 것 같다.

그러다가, 이번에 Docker에 꽂혀 Docker를 사용하려고 설치를 했는데, 문제가 갑자기 잘 동작하던 VMWare Workstation이 오류를 뱉으면서 실행이 안되는 것이였다. VMWare Workstation 프로그램 자체는 잘 뜨는데, VM만 실행하면 아래와 같은 다이얼로그를 보여주고 더 이상 실행이 안된다.

Hyper-V 계열의 설정이 Enable 되게 되면 VMWare Workstation을 쓸 수 없다는 메시지 였다. 즉, Hyper-V의 기능을 비활성화 해달라는 메시지 같았다. 

이 메시지를 처음 봤을때 상당한 고민에 빠졌다. Docker가 반가상화기 때문에, 내 개발 PC의 부담을 줄이면서 가상화를 구축할 수 있어 매우 마음에 들어 잘 되었다고 생각했는데, 매번 테스트 때는 GUI 기반의 OS로 자주 하기 때문에, 전가상화를 지원하는 솔루션이 필요했기 때문이다. 그렇다고 VMWare Workstation을 포기하고 Hyper-V로 전환하기에는 Hyper-V의 강력한 기능 대신 그 관리도구나 Console 접속 도구가 너무 구려서 사용하기가 좀 그랬다.

양자택일을 강요받는 느낌이여서 매우 불편했다. 

그러다가, 저 다이얼로그 박스의 URL을 클릭해봤고, 해당 내용에 대한 KB가 나온다.

kb.vmware.com/s/article/2146361

내용을 살펴보니, 내 예상대로 Hyper-V와의 연동 문제였던 것이다. 

근본적으로 해결하는 방법은 다음과 같다.

먼저 Windows가 20H1 이상의 버전으로 설치되어 있어야 한다

동시에 VMware Workstation도 15.6.5 이상 버전을 설치하면 된다는 것이였다.

다행히 최근 개발 PC는 20H2를 설치해서 업그레이드가 완료된 상태. VMware Workstation을 확인해보니, 15.6.2 였다. 즉 VMware Workstation 만 업그레이드 하면 되는 것이였다.

그리고 업그레이드를 했더니... 가상머신이 뜨는 것이다. 감격...

그런데 잠시 후... 괴이한 현상에 다시 당황했다. 이상하게 네트워크가 잡히지 않는 문제가 발생했다. 분명 예전에 Bridge 설정으로 잘 연결되어 있었던 가상머신인데, 인터넷이 연결안된다는 것이였다. 심지어 DHCP를 아예 받지조차 못한 것이였다. 

확인해보니 Netowork 카드 내에 설치된 각종 구성요소들 중, 가상 머신 관련된 구성요소들의 충돌이였다.
이 부분을 설정하려면 도스창 혹은 Windows 키 + R 을 눌러 나오는 입력창에 아래의 명령을 넣는다.

control ncpa.cpl

그러면 네트워크 목록이 나오는데, 그 중 자신의 네트워크 카드에 해당하는 곳에서 더블클릭해서 들어간 뒤, "속성"을 누르면 된다.

그 안의 속성을 보면 다음 두가지 항목이 모두 체크되어 있을 것이다.

• VMware Bridge Protocol
• 브리지 드라이버

이 두 개가 동시에 설정되어 있어 오류를 내는 것이다.

방법은 둘 중 하나를 꺼야 한다. 만일 VMware 쪽을 살리고 싶으면 아래의 브리지 드라이버를 끄고, 반대로 Docker 쪽을 살리고 싶으면 VMware Bridge Protocol을 꺼줘야 한다. 

다시 고민... 둘 줄 하나라니...

그래서 나 같은 경우에는 Wireless LAN 이 하나 남길래, 그 쪽에서는 역으로 설정해서 인터넷에 연결해버렸다.

즉, 유선 랜에는 VMware Bridge Protocol 만을 켰고, 무선 랜에는 브리지 드라이버만 켰다.

확인해보니, VMware Workstation 내의 가상머신들도 정상적으로 네트워크가 되었고, Docker의 Container 들도 정상적으로 통신이 됨을 확인했다. 결국 이렇게 가상머신들을 공유해서 쓰려면, 물리적인 네트워크를 분리해서 구성해야 할 것 같다. 

Docker를 설치하긴 했는데, Docker를 핸들링하려면 매번 Command Line으로 마술부리듯 끊임없이 입력해야 한다. 물론 Command Line 입력 작업이 매우 직관적이기 때문에, 명령만 잘 구성한다면 매우 편리하게 사용할 수도 있다. 하지만, Windows 기반의 GUI 프로그램에 익숙해져버린 나 같은 경우 이 명령창 기반의 작업은 Docker를 전체적으로 관리할 때 매우 어려움이 컸다. 이전 상태 값에 대한 파악을 하려고 할 때마다 명령을 넣어 이리저리 컨텍스트를 매 순간 순간 마다 입력해서 확인해야 했기에 기억력이 떨어지면 이 내용을 자주 놓치고 반복하게 된다.  그래서 GUI 기반의 도구를 찾아보다가, Portainer 라는 제품을 확인했고, 이 Open Source 기반의 도구라면 Docker의 관리가 편해질 것 같아 설치를 진행해본다. 

다만, 이 글 역시 밑의 글 처럼 다른 블로그의 포스트 된 내용을 적용해보고 내 나름대로 정리했다.
원본 글은 아래의 URL을 통해 접근이 가능하다.

psychoria.tistory.com/684

시작 전 확인 내용

사실 자신이 사용하고 있는 운영체제 및 설정 값은 각기 다른 모습을 갖추고 있어 딱 이것이다 라는 글을 찾기가 매우 어렵다. 내가 여기에 적은 글도 수많은 상황 중 하나일 뿐이다. 

운영체제는 Ubuntu 이며 ubuntu-20.04.1-live-server-amd64.iso 이미지로 설치했다.

클린 인스톨 상태에서 docker-ce를 설치했으며 현재 버전 아래와 같다.

Client: Docker Engine - Community
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:18:20 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:16:15 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

 그리고 Docker의 편의를 위해 Docker 그룹에 내 아이디도 포함시켰다. 

설치 전 단계

Potainer를 설치 구성하기 전에, 이 Potainer에서 사용되는 각종 설정값, 데이터들을 저장하기 위한 폴더를 정의해 주는 것이 좋다. 안그러면 Potainer의 가상 HDD 내에 저장되게 되는데, 이 안의 내용을 접근하려면 생각보다 번거롭다. 그래서 데이터 부분만을 저장하기 위한 디렉토리를 생성한다. 나 같은 경우에는 var를 잘 이용하기 때문에, var 안에 디렉토리를 생성했다.

sudo mkdir -p /var/portainer/data

다음에는 바로 이미지를 자동으로 다운 받아 설치되어 실행되게 명령을 넣는다.

docker run -d -p 8888:9000 --name=portainer --restart=unless-stopped -v /var/run/docker.sock:/var/run/docker.sock -v /var/portainer/data:/data portainer/portainer

명령 줄이 매우 긴데.. 그 중 몇가지만 짚어서 설정해주면 된다.

-p 8888:9000

이 옵션에서 앞의 숫자와 뒷 숫자를 ":" 로 구분한다. 여기서 앞의 숫자는 외부에서 접근할 때의 포트 번호고 뒷 숫자는 Docker Container, 여기서는 Potainer 가상 머신의 포트 번호를 의미한다. 이 옵션이 없으면 Potainer의 9000번 포트를 접근할 수 없다. 바깥에서 보이는 포트를 Container 안의 포트와 연결해주는 작업으로 이해하면 된다.

-v /var/portainer/data:/data

거의 맨 뒤쪽의 옵션인데 -v 로 되어 있으며, 앞의 포트 처럼 ":"를 중심으로 두개의 경로가 있다. 이 중 앞의 경로가 Docker가 실행되고 있는 호스트 컴퓨터의 경로이고, 뒤의 경로가 Container 내부에서 사용되는 경로이다. 즉 /var/potainer/data 라는 디렉토리를 Portainer Container에서 /data 처럼 쓰겠다라는 의미가 된다. 앞의 설치 단계에서 만든 경로를 넣어주면 된다. 

자 명령이 완성되어 입력하면 자동으로 이미지를 다운 받고, 자동으로 실행된다.  실행되고 있는지 확인하고 싶으면 아래와 같이 명령을 넣어보면, 결과를 볼 수 있다.

docker container ls

사이트 접속하기

Docker가 실행 중인 PC의 아이피 주소에 8888 포트를 넣어 접속하면 아래와 같이 사이트에 접속이 된다.

http 기반으로 접속이 되며, 맨 처음 접속하는 순간 관리자 계정을 최초로 생성하기 위한 화면이 뜬다. Username은 기본값으로 admin으로 되어 있다. 바꿔도되긴 하는데, 그대로 둬도 무방하다. 그리고 계정에 대한 암호를 만들라고 나오게 된다. 암호를 적절히 만들어 넣고, "Create user"를 한다.

다음에는 이 Portainer 사이트가 관리할 Docker의 사이트 정보를 넣도록 하는 부분이 있다. 원격에 있는 Docker를 설정할 수도 있고, Agent를 기반으로 할 수 있으며, 심지 Azure와도 연계가 된다. 다만 여기서는 현재 설치된 Docker를 관리할 것이므로 Local을 선택한다. (이를 위해서 위의 docker run 할 때 옵션에  socker 부분에 대해 -v 옵션으로 설정해서 실행한 것이다.)

이제 Connect를 눌러보자

그러면 현재 Docker 서버의 Overview를 볼 수 있으며, 그 안에 들어가서 각종 Container나, Image 등을 확인해볼 수 있다.

정리하면...

물론 아예 Docker의 이해가 없이 쭉 따라하기 식으로 구축해도 무방하긴 한데, 이 Portainer를 사용하려면, 어느정도의 Docker의 이해가 필요하다. 일단 설치를 하더라도, 가급적이면 명령어 기반의 동작 방식을 어느 정도는 연습을 하는 것을 추천한다. 나 역시도 다양한 명령을 입력해보고, Docker를 이리저리 사용하면서 조금씩 기능을 깨닫는 부분이 있었다.

우분투 Docker 설치라는 검색어로 뒤져보면, 많은 포스트들을 볼 수 있다. 다만, 검색 결과의 내용에서 자신의 설치환경과 맞는 내용을 찾기 어려울 수 있어 이 곳에 남긴다. 이 글의 원본은 다음 URL을 통해서 접근이 가능하다.

hiseon.me/linux/ubuntu/install-docker/

먼저 나는 Ubuntu 서버 버전인 ubuntu-20.04.1-live-server-amd64.iso 을 기반으로 설치했다.

준비

여기서는 기존에 설치된 Docker를 날리고 새롭게 구축하기 위해 수행하는 작업으로 기존 버전을 삭제한 뒤, Package를 다운로드 받기 위한 명령어들을 나열한다. 명령은 총 3가지 인데, 하나는 패키지 날리는 것, 다음은 패키지를 업데이트하고, 마지막으로 이 Docker 설치에 필요한 패키지들을 설치하는 작업이다. 

sudo apt-get remove docker docker-engine docker.io

sudo apt-get update 

sudo apt-get install apt-transport-https ca-certificates curl software-properties-common

그리고 난 뒤, 저장소 부분을 업데이트 해준다.
Docker 저장소 관련된 인증 키를 적용한 뒤, 저장소 리스트를 추가한다.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

도커 CE 설치

이제 실질적인 Docker를 설치한다. 이 때 설치하는 도커는 Command Line 환경을 위한 Docker인데, 맨 뒤에 ce 라고 붙는다. 이 패키지를 다음 명령을 넣어 설치한다.

sudo apt-get update && sudo apt-get install docker-ce

마무리

사실 윗 단계에서 모든 과정은 끝이 난 것이긴 하지만, Docker의 기능을 사용하려면, root의 권한이 요구된다. 그렇다고 docker를 실행할 때마다 sudo를 넣기에는 귀찮기 때문에, 일반 계정에서도 docker를 사용할 수 있게 해주는 방법이 있다. 다음과 같은 명령을 넣으면 된다.

 sudo usermod -aG docker $USER

그러면 현재 로그인된 계정에 대해 권한을 획득할 수 있다.

다만, 실질적인 적용은 Logout 후 다시 Login을 해야 된다.

위에 업무 진행을 보고하기 위한 주간보고를 매주 작성 중이다.

그런데, 주간보고 내에는 진척도라는 것이 있는데, 이 진척도를 작성하는게 매번 곤욕이다. 그 와 함께, 매주 계획을 쓰게 되는데, 쓰는 시점을 기준으로 다음 주 작업 내용을 정리하고자 할 때도 매번 고민 덩어리다.

그러다가보니, 진척 및 업무 관리에 대한 측면에서 이 과정을 어떻게 정리할까 하다가보면, WBS가 떠오르게 된다.
다만, WBS라고 적긴 했는데, 사실 WBS의 전체적인 양식이나 작성 방법이 필요한 것이 아닌, WBS를 가장 적절하게 표현하는 Gantt 차트가 떠오른다는 표현이 더 정확하다. 그래서 이 Gantt 차트에 대한 고민을 하고 있다.

Gantt 차트 작성 방법

역사적으로는 좀 되는 작성 방법이다. 20세기 초(1919년)에 헨리 간트라는 사람이 제안한 작성 방식인데, 각 작업을 막대 형태로 진척률을 관리할 수 있도록 하는 방식이다. 

지금은 대부분 컴퓨터를 이용해서 작성하고 있어, 예전 손으로 작성할 때 보다, 매우 편하고 빠르게 확실하게 작성할 수 있다.

작성 도구

역사적으로 좀 오래되기도 했고, 다양한 분야에서 활용되고 있어 이 차트를 작성하는 도구들도 매우 많다. 더욱이 구독제, Web-Based의 추세에 맞게 다양한 클라우드 방식을 제공하고 있다. 물론 전통적인 Application(Windows용 혹은 Mac용, Linux 용)들도 제품으로 제공된다.

TeamGantt

많은 곳에서 추천하고 있으며, 나 역시도 잠시 사용해 봤는데, Web이라고 믿겨지지 않는 다양한 옵션들과 관리도구들을 제공한다. 상당히 괜찮은 솔루션 같다. 하지만, 일단 비용이 좀 들어간다. 대략 10명 정도의 팀을 위해서 사용하려면, 한달 기준 약 10만원 정도의 구독 비용이 든다. 뭐 팀 사용비가 넉넉히 떨어지는 좀 규모가 되거나 매출이 되는 회사면 모르겠지만, 영세하고 매번 적자 행진을 걷는 회사에서는 부담이 된다. 그리고 이 모든 데이터가 TeamGantt 회사 서버에 저장된다. 물론 대외비를 할 만큼의 중요한 프로젝트는 아니지만, 그래도 왠지 자료가 외부에 놓여 있다는 점은 매우 마음에 걸린다. 마지막으로 인터넷이 연결되어 있어야 사용이 가능하다. 인터넷을 사용할 수 없는 고객사 안에서 진행하는 프로젝트의 경우 관리하기 그다지 수월해 보이지는 않는다.

MS Project

Office 제품군 중, 가장 비싼 몸값을 자랑하는 솔루션으로 Project 관리도구이다. 최소한 PC에 설치하여 사용되는 솔루션에서 최상위의 기능을 갖추고 있는 제품으로 생각한다.

내가 원하는 Gantt 차트 부터 리소스 관리, 네트워크 기반의 평가까지 다양한 View와 자료 정리 도구까지 지원한다. 게다가 Office Subset이다 보니, 리포트 만들때도 매우 편리하게 연계가 가능하다. 아마 2010 부터 서버 제품도 지원하고 있어 MS Project Server나, SharePoint 등을 이용하면 자료를 웹에다가도 리포팅이 된다. 

하지만, 매우 비싸다!, 그리고 다른이들과의 공유도 쉽게 할 수 있지는 않다.(파일공유를 하거나 웹에 Publishing을 해야 될 듯)

ProjectLibre

이 제품은 최초 Open Source로 시작해서 상업용 버전도 같이 제공하고 있다.  MS Project와 그 결을 같이하지만, 이 제품의 특징은 어느 OS 든 동작할 수 있도록 다양한 버전을 제공한다는 점이다. MS Project에서 제공하는 대부분의 기능들이 제공하며, 심지어 파일도 호환이 가능하다. 가장 큰 장점은 역시 Open Source 그러니까, Community 버전은 무료라는 점이다. 

하지만, UI를 보면 매우 투박하다. 뭔가 조작도 세련되지 않아, MS Project 처럼 직관적이며, 편하게 입력하게 제공되지 않는다. 게다가 몇몇 기능의 경우에는 정말 기능을 제공하는 정도의 레벨이지, 정확하고 오류 없이 제공되지 않는 경우도 있다. (지금 최신 버전은 사용 못해봤지만, 예전 버전의 경우 한글 입력이 깨지는 경우도 종종 있었다).

위의 제품들 말고 더 다양하고 많은 제품들을 찾을 수 있다.

문제는...

검색해보면 이 Gantt 차트를 처리하기 위한 솔루션들은 많지만, 대부분은 유료거나, 웹 기반이 주류다. 보안 등을 이유로 내부 네트워크만 사용하거나, 자료를 내부적으로만 보관하고 싶을 때의 대응이 어려웠다. 아예 이참에 Gantt 차트 그리는 도구를 만들려고도 생각했다. 문제는 저 Gantt 차트를 그리는 컨트롤인데, 이 부분에서 좌절을 해서 더 이상 진행을 안하고 있다. 

그래서 어떻게 표현할까 고민하다가, 결국 Redmine 으로 돌아오게 되었다.

결국 Redmine

사실 Redmine에서 기본 기능이 아니였는데, 아마 2.0 대 부터 등장하면서 지속적으로 업그레이드가 되어 현재 각 Task에 대해서 자동으로 그려주고 있다. 심지어 pdf 로 내보내기까지 지원된다. 물론 한글 문제가 간혹 발생되긴 하지만, 현재 버전에서는 이 역시도 잘 표현되는 것 같다.

이제 남은 숙제는 바로 이 Task 만드는 작업에 대한 규칙을 수립하는 작업이다. 정의하는 규칙이나, 진행 방식 정의 등을 담아 Redmine에 등록하고 정리하고 필요할 때마다 Gantt 차트를 Export 하도록 하는 것이다. 

궁극적으로는 이 Redmine 서버에서 직접 주간보고를 뽑아낼 수 있도록 하는 것이다. 

개발자에게 중요한 자질은 여러가지가 있겠지만, 내 기준에서는 3가지라고 본다.

첫번째는 전체를 아울러 볼 수 있는 시선.

두번째는 디테일을 확인할 수 있는 시선.

세번째는 편견없이 다양한 오류를 받아드릴 수 있는 여유.

다 중요한 내용이지만, 이 중,특히 디버깅 작업에서는 세번째 자세가 필요하다고 본다. 
디버깅을 하려면 다양한 시점으로 확인을 해야하는데, 최소한 나와 같이 작업하는 사람들 대부분은 스스로에 대해서는 매우 관대하여 심하면 완전무결을 기준으로 생각한다는 점이다. 최소한 자신이 직접 관여하거나 만든 코드 부분에서는 문제가 없다고 가정하고 생각한다. 그러다보니, 매번 문제를 간과하거나 이상한 곳을 기준으로 진행하는 경우를 많이 보았다. 

물론 자신의 코드가 이상이 없다는 생각에서 출발해야, 덜 피곤할 수 있다. 문제가 있는지 없는지를 증명하는게 이게 장난 아니다. 있지도 않은 문제점을 찾아 증명하는게 시작도 문제고 진행과정도 문제다. 편한 길을 찾아보는게 역시 자신의 코드를 기준으로 남의 코드의 흉을 보는 것이다. 남의 코드를 보면 매사가 의심증 자체다 보니, 조금만 자신과 다르면 다 오류로 감지할 수 있다. 또 그 의구심을 그대로 쏟아보면 진짜 오류 같기도 하다. 여기에 한 술 더떠 디버깅 중인 사람이 권력자(설계 담당자, 상위 직급 등등)인 경우라면 이건 완전히 Hell 이된다.

그래서 난 항상 디버깅을 이야기 할 때, 스스로를 의심하라는 것이다. 과연 진짜 스스로의 코드가 옳은가? 흐름상으로는 맞을지 모르지만, 혹시 나비효과의 나비 날갯짓 짓거리를 하고 있는 것은 아닐까? 혹은 내가 만든 코드를 복사한데서 다르게 동작한 것은 아닐까? 의도치 않게 호출되는 순서가 바뀐건 아닐까? 정말 안전하게 디자인되어 구현되어 있나?

일단 스스로를 좀 엄격하게 대하고, 확인하는 습관을 들였으면한다.

이번에도 스스로의 코드 부분에서는 당연히 문제 없다고 간주하고 이야기를 하다가 결국 나와 이야기가 잘 정리가 안되서 결국 한소리를 하고 난 뒤 쓴다. 

6.X DSM이 구축된 시놀로지를 가지고 있다면, Docker를 이용한 Redmine 설치가 가능하다. "시놀로지 Redmine 설치" 같은 검색어로 Google에서 검색하면 시놀로지를 이용한 Redmine 설치방법이 매우 자세히 잘 나온다.

그런데, 회사에서 사용하려다보니, 자연스럽게 SSL 적용이 필요했고, 이를 위한 작업을 하려고 하는데, 이 방법이 잘 소개 되지 않는다. Reverse Proxy를 이용하라든가, Docker 이미지 내 SSL 인증서를 탑재하라는 등 다양한 의견들이 있었다.

문제

최초 시놀로지의 Docker 기반의 Redmine을 기본 설치하면 30002 포트로 열리는데, 이 포트로 다이렉트 하게 접속 ( http://192.168.99,100:30002 )하면 잘 연결되었다. 그래서 방화벽에서도 NAT 로 해당 포트를 연결해서 제대로 연결된 것을 볼 수 있었다. 이번에는 HTTPS 로 변경하려고 했다. 

제어판 -> 응용 프로그램 포털 -> 역방향 프록시 까지 이동한 뒤,

 생성을 통해서 다음과 같이 만들었다.

즉 외부에서 https://myredmine.server.com:30003 으로 접속하면, http://localhost:30002 로 접속을 해준다는 의미이다. 다른 서버도 이런식으로 설정했었다. 그리고 방화벽에서도 30003에 대해서 열어주었다. 여기까지는 순조로왔다. 최초 접속을 해보니, 정상적으로 Redmine이 떳다.

그런데, 문제가 Submit만 하면 400 Bad Request가 떴다. 즉 "확인" 버튼만 누르면 무조건 저 페이지가 뜨면서 정상적으로 동작하지 않았다. 이 부분을 해결하기 위해 다양한 사이트를 뒤적거리기 시작했다.

해결 방법

의외로 간단한 문제였다. Reverse Proxy를 적용할 때, HTTPS 적용을 하려면, 이 Redmine의 컨테이너에 환경변수를 하나 추가해야 한다. "REDMINE_HTTPS" 를 true로 설정해야 한다. 물론 이렇게 하면 http로 접속이 제대로 안된다. 

방법은 다음과 같다.

먼저 패키지 센터에 들어가 "설치됨" 을 선택한 뒤, Redmine 항목에 들어간다. 그러면 아래와 같은 화면이 나오는데, 실행 중인 경우 "중지" 버튼을 눌러 중지 시켜준다.

그리고 난 뒤, Docker 설정 창에 들어간다. 컨테이너를 선택하고 이번에 새롭게 만들어진 redmine 컨테이너를 선택한다. 이 상태에서 편집을 누른다.

설정 창에서 "환경" 탭을 클릭 한 뒤, "+"를 클릭한다. 그러면 새롭게 입력할 수 있는 창이 뜨는데, 그 안에 "REDMINE_HTTPS" 라는 이름을 넣고, 값에는 "true" 라고 넣는다.

이제 다시 패키지 센터로 돌아가 "중지 됨" 상태를 "실행 중" 상태로 바꾸기 위해 "실행" 버튼을 클릭하면 된다. 

결론

정확한 원리는 모르지만, Reverse Proxy에서는 https로 받은 신호를 제대로 Redmine 서버에는 돌려주는데, Redmine 서버에서 html을 만들 때, http 코드로 생성되서 발생된 것으로 생각한다. 그래서 Docker Container 설정 중 환경 변수로 설정함으로써, 모든 I/O를 https 로 처리될 수 있도록 해주는 것 같다. 

단, 이 작업은 외부에 접근하여 연결할 수 있는 도메인주소가 필요하고, SSL 인증서가 필요하다. 유료 도메인이 없으면, DDNS를 찾아 등록하고, 유료 SSL 인증서가 없다면, Let's Encrypt를 이용해서 생성해도 된다. 
"시놀로지 DDNS" 로 검색하고, "시놀로지 Let's Encrypt"를 검색하면 방법이 나온다.
이렇게 해서 최소한 NAS가 도메인 주소로 연결하고 인증서까지 잘 적용되었다는 상태에서 아래의 단계를 진행해야 한다.

WSL 기반의 우분투를 설치해서 파일 시스템을 보면 완전 리눅스다. 그 사실이 맞긴 하다. 그런데, 이 가상머신은 어디까지나 Windows 위에서 동작하는 구성이기 때문에, 분명 Windows 와 연결이 있다.

간혹, Windows에 있는 파일을 가져다가 쓰고 싶을때가 있는데, 이 때 좀 당황스럽긴 하다. 물론 외부 NAS나, 클라우드 파일 혹은 SAMBA 클라이언트를 이용해 파일 공유로 가져오는 방법등 다양하게 있지만, 같은 PC에 있는 상태에서 파일을 가져가는게 중간자를 거쳐가는 작업이 매우 귀찮을 수 있다.

이 때 Windows에 있는 파일을 가져오는 방법을 설명한다.

많이 어렵진 않다. 위치만 기억해주면 된다.

cd /mnt

그 안의 내용을 모면, 현재 Windows에서 사용 중인 모든 드라이브를 볼 수 있다. cd를 통해서 접근하면 된다.

다만, sudo를 이용해 관리자 권한이 없으면 Write가 되지 않으므로 가급적 편집을 하고 싶으면 직접 하지 말고, 로컬로 복사 한뒤 작업 후에 다시 덮어쓰는 방식을 추천한다. 그리고 Temp와 같은 폴더를 통해서 처리해주는 것을 추천한다.

WSL 기반의 우분투를 설치해서 사용해보면 알겠지만, 기본적인 구성요소들은 설치되어 있다. python도 되고, perl은 apt-get install을 통해서 받으면 된다. 그런데, 다른 PC에서 이 Linux의 기능을 사용하고 싶을 때가 있는데, 분명 Open SSH 서버가 설치되어 있음에도 불구하고 putty로 연결할 수 없었다.

혹시나 해서 아래의 명령을 넣어 확인해봤는데, openssh 서비스를 실행해 봤더니, 설치만 된 것이지 실제 실행은 안된 것이였다.

지금까지 리눅스 쓰면서 이 부분에 대해서 확인을 안했던 이유가, 대부분 Ubuntu를 설치하거나 OpenSSH 서버를 설치 후 실행을 하면 자동으로 적용되었던 부분이 안되어있는 것 같았다.

지금부터 이 SSH를 활성화 해보도록 한다.

1. SSH용 host key 적용

서비스를 실행 하면 위의 이미지 처럼 나오는 단서는 "sshd: no hostkeys available -- exiting." 이다 . 즉 hostkey가 없어서 실행을 못한다고 한다. 이 문제를 검색해 보자 다음 사이트를 볼 수 있었다.
www.garron.me/en/linux/sshd-no-hostkeys-available-exiting.html

여기서 "ssh-keygen -A" 명령을 넣으라고 나왔다. 그래서 다음과 같이 명령을 넣었다.

sudo ssh-keygen -A

그러면 새로운 host 키가 생성되었다고 표시된다. 이제 서비스를 다시 시작하자

sudo service ssh restart

그러면, 이제 ssh 서비스는 정상적으로 실행된다.

2. 암호 기반 로그인 처리

서비스가 활성화 되었으니, 이제 PuTTY로 연결해보자. 연결할 때의 주소는 localhost 포트(연결 대상을 ssh로 하면 자동으로 22번이 됨)는 SSH로 하면 된다. 그러나 아이디를 넣는 순간 다음과 같이 뜨면서 더 이상 진행되지 않는다.

이 문제는 SSH 서버 설정 때문이다. 기본적으로 SSH가 설치되면, 로그인 처리 없이, 인증서(SSH용 SSL 인증서)만으로 로그인이 되도록 설정되어 있어서 그렇다. 이 설정이 기본값으로 되어 있어, 아이디를 넣는 순간 PuTTY에서는 위와 같은 오류를 내며 연결이 되지 않는다.

이를 설정하려면 다음 명령을 입력해서 설정 값이 담긴 텍스트를 열어야 한다.

sudo vi /etc/ssh/sshd_config

약 58번째 줄을 보면 PasswordAuthentication 이라는 항목이 보이는데, no로 되어 있는 것을 yes로 변경한다. 즉 암호 기반의 연결을 지원하도록 하는 설정이다.

다시 서비스를 다시 시작한다.

sudo service ssh restart

그러면 PuTTY를 이용해 localhost:22 로 다시 접속하면 정상적으로 접속됨을 확인할 수 있다.