그누보드6 docker 에 대해서 문의드려요..

[purndal]

서버포럼 purndal입니다. docker를 보다가 궁금한 것이 있어서 github에 글을 남기려다 이곳까지 오게 되었네요. ㅎ
다름이 아니라 이번에 g6에 대해서 docker compose를 사용해서 올려보는 과정에서 궁금한 것이 있어
이렇게 문의드리게 되었네요.

우선 적용한 코드네요.. 작동은 잘 됩니다.

version: "3.8"
services:
  app:
    container_name: gnuboard6
    image: navystack/gnuboard-g6:nightly-latest
    restart: always
    volumes:
      - ./data:/app/data
    environment:
      TZ: Asia/Seoul
    ports:
      - 8000:8000
    depends_on:
      - sql
    networks:
      - g6
      - npm-network
  sql:
    image: postgres:16-bullseye
    restart: always
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: 6VqahNQruCdfnzKSFaUmE8pUd2o7Ee
      TZ: Asia/Seoul
    volumes:
      - ./postgresql:/var/lib/postgresql/data
    networks:
      - g6
networks:
  g6: {}
  npm-network:
    external: true

정상적으로 웹 서비스가 올라가는 것을 확인을 하였습니다. 여기서 조금 의아한 것이 내부에 user를 g6로 구성해 주셨더라고요.
하지만 docker을 올려진 폴더를 보면 root로 구성된 것을 확인했습니다.
puid pgid 를 넣어서 user로 권한을 줄 수 없을까? 하는 생각이 들더라고요.. dockerfile 로 이미지를 만들어 봤지만
아직 올리고 테스트를 하는 정도의 스킬? 을 가지고 있지 않다보니 힘이들더라고요 ㅎㅎ.

그리고. dockerfile 에서 VOLUME /g6/data 라는 볼륨을 data 폴더만 연결을 해주셨는데.. 데이터 저장파일을
백업하기 위해서는 필요하다고 생각을 하지만. 그냥 보기에는 g6를 바로 연결해 주심이 좋지 않을까 하는 생각이 들었습니다.
예로.. .env 파일의 경우 셋팅 파일이 들어가 있는데 마지막 줄의 도메인 설정 부분을 해주는게 있더군요.

# www.gnuboard.com 과 gnuboard.com 도메인은 서로 다른 도메인으로 인식합니다. 
# 쿠키를 공유하려면 .gnuboard.com 과 같이 입력하세요.
# 이곳에 입력하지 않으면 www 붙은 도메인과 그렇지 않은 도메인은 쿠키를 공유하지 못하므로 
# 로그인이 풀릴 수 있습니다.
COOKIE_DOMAIN=''

이 것을 수정을 하기 위해서는 docker image 에 들어가서 수정을 하고 나와야 하지만 백업을 하더라도 data만 백업하니
다시 구성시에 문제가 발생하지 않을까 하는 생각이 들었습니다.

템플릿 수정도 그렇고..

그래도 만들어주신 docker 이미지를 활용해서 우선 그누보드를 띄워두고 있습니다. 너무 감사합니다.
게시판으로 이루어진 간단한 파일 저장용 웹 서비스가 필요해서 띄워놓긴 했는데 어떻게 활용할지 참 머리속이 복잡하긴 하네요 ㅎ. 제목이 특수문자가 많다보니 게시판을 이용해서 정리해야 하다보니 더욱.. 고통이 따르네요. ㅎ.

이상입니다. :)

[navystack]

1. 내부 UID와 GID는 1001로 설정했습니다. (보안을 위해서)
   혹시 실행하는 사용자가 root는 아니신가요? 이 부분은 확인해 주시면 감사하겠습니다.
   ( 도커 파일에 주석을 달은 것처럼 /data 폴더 관련해서 docker build kit에 오류가 있는 건지, Github 워크플로우 런타임에서 오류가 나는건지 파악이 안됩니다. )

2. 아직 그누보드에 정식 태그가 붙지 않았고, 아직 머지가 안되어서 조금 조심스러운 부분이 있습니다.

3. Nginx관련 서버블록도 최적화 해 두었지만 역시 조금 조심스럽네요 :)

4. 말씀해주신 우려 사항은 사실 최우선 고려사항입니다. .env, config.json파일 수정 없이 docker-compose.yml의 환경변수에서 탬플릿으로 바로 쏘아주게 하려고 준비중입니다. :)

5. 또한 g6자체를 도커 볼륨으로 잡게되면, 이미지 업데이트시 반영이 안됩니다. 이를 위해서는 로직을 수정해야 하는데, 사실 의존성 관련해서 requirements.txt에만 의존하다보니 인스톨 시점 마다 사용하는 버전이 달라지고 있습니다.

현재 Qemu를 사용한 빌드를 하면 약 50퍼센트의 확률로 빌드가 되었다 안되었다 합니다.

6. 의존성을 관리하는 방식을 제안 하고 싶으나, 깊게 관여할 수 없고, 깃허브 커밋메시지는 3.7 대응이라 적혀있음에도 깃허브 Readme.md에는 3.8 ~ 3.12로 되어있는 등 아직 어수선합니다 :)
   의존성 관리를 pip로만 하시는 듯 합니다.
   사실 이게 제가 파이썬이랑 엮이기 싫었던 부분이기도 합니다 :)

7. 특수 문자가 많다면, 상당히 고려를 많이 하셔야 할 것입니다. 라이믹스도 그렇고, 그누보드도 그렇구요. 관련된 라이브러리가 업데이트 되면, 이스케이핑이 되지 않을수도 있을 것 같네요 :)

[purndal]

@navystack

지금 리눅스 및 서버를 본격적으로 만진 것이 1년도 되지 않아서 그냥 하라는 대로 본 것대로 기준을 삼아서 진행하다 보니..
그 범위에서 벗어나지 않고 있기도 합니다.

현 dockge를 사용해서 root 일 듯합니다. 실행은 기본적으로 사용하라는 /opt/ 폴더 root로 설정되어 있습니다.
그다음 관리는 dockge로 관리하고 있습니다.

g6의 경우 정상적으로 동작을 합니다. 만 레이아웃 수정이나 템플릿?이라고 하는 것들을 넣어두려고 하면
docker 쉘에 접속을 해서 작업을 해야 하는 경우가 생긴다고 생각됩니다.

uid 나 gid를 설정을 할 수 없을까 하는 것은 수정 가능한 개인 폴더에 연결을 하고 바로 수정을 할 수 없을까
하는 부분 때문에 이야기를 들었습니다. 파일 저장은 /data 폴더이지만 나머지 설정은 다른 폴더에 있으니까요..
그래서 ./data:/app 로 하면 될 줄 알았는데 이거 처음 dockerfile 생성 시 volume을 설정해야 하더라고요 ㅎㅎㅎ.
하다 보니 하나씩 배워나가게 되더군요..

지금 테스트 한 곳은 oci A1 uid 1002 / 개인서버 uid 1000 입니다.. 아.. g6는 다 동작 됩니다..

[navystack]

아 이해했습니다. 제가 테스트 환경에서, 볼륨을 쓰다보니.. 그러네요. 선생님 말씀이 맞습니다.

수정하겠습니다. 감사합니다.

탬플릿은 도커 컨테이너 안에서 작업하지 않기 위해서 docker-compose.yml에서 environments에 기록하면 그 값을 받아서 하게 하려 수정하려 합니다.
탬플릿은 시작할 때 주입됩니다.

우선은 data경로를 우선적으로 수정하고, 그누보드에 PR올린 것은 수정하지 않겠습니다.
메인테이너에서 피드백이 있었으면 좋겠는데 우선순위에서 밀리는지 제가 어떻게 할 방법이 없네요 :)

고맙습니다 :)

[navystack]

@purndal 안녕하세요!
방금 전에 이미지를 다시 배포했습니다. 선생님이 우려하는 Volume 관련을 수정했습니다.

확인해 주시면 감사하겠습니다.

[purndal]

@navystack

이거 제가 괜히 잘 모르면서 이상한 이야기를 한 것이 아닌가 싶기도 합니다. ㅠㅠ;;
혹시 몰라서 빠르게 설치하고 테스트해 봤습니다.
dockge로 올려봤으며. 에러가 나타나더군요. ubuntu amd64와 oci arm 두 군대 해봤습니다.

와 같이 오류가 나왔습니다. 그래서 혹시나 해서 data 폴더를 보니 연결될 줄 알았는데 파일이 없더라고요.
전 docker image의 폴더와 매핑을 하면 그 속의 파일이 전부 보여줄 줄 알았는데 추가로 생성되는 파일만 보이는 듯합니다.

---

아래 코드로 수정을 하여서 실행해 봤습니다.

우선 폴더를 생성하고 실행해 줬습니다.

sudo mkdir -p data

compose 를 입력해줬습니다.

version: "3.8"
services:
  gnuboard6:
    container_name: gnuboard6
    image: navystack/gnuboard-g6:nightly-latest
    restart: always
    volumes:
      - gnuboard6-data:/g6
    environment:
      TZ: Asia/Seoul
    ports:
      - 8000:8000
    depends_on:
      - gnuboard6-postgresql
    networks:
      - g6
      - npm-network
  gnuboard6-postgresql:
    image: postgres:16-bullseye
    restart: always
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: 6VqahNQruCdfnzKSFaUmE8pUd2o7Ee
      TZ: Asia/Seoul
    volumes:
      - ./postgresql:/var/lib/postgresql/data
    networks:
      - g6
volumes:
  gnuboard6-data:
    driver: local
    driver_opts:
      o: bind
      type: none
      device: ./data/
networks:
  g6: {}
  npm-network:
    external: true

정상적으로 파일이 올라오더군요.
정말이지 잘 모르는 상태에서 이야기는 조심해야 할 듯 합니다. ㅠㅠ;;

또 하나의 걱정이 지금 올려져 버린 이미지를 누군가가 사용하고 있다면 문제가 되지 않을가 하는 걱정도 생기더군요..
이것참.. 걱정이 크네요 ㅎㅎ. ㅠㅠ;;

[navystack]

@purndal 님,

    volumes:
      - gnuboard6-data:/g6
volumes:
  gnuboard6-data:
    driver: local
    driver_opts:
      o: bind
      type: none
      device: ./data/

    volumes:
      - ./data:/g6

1. 첫 번째 예시에서는 Docker Compose 파일의 volumes 섹션을 사용하여 볼륨을 정의하고, 해당 볼륨을 컨테이너에 마운트하고 있습니다. 이것은 볼륨 이름을 지정하고 해당 이름으로 호스트 머신과 컨테이너 간의 데이터를 공유하는 방법입니다. 볼륨은 호스트 파일 시스템의 특정 위치와 컨테이너 내부의 특정 위치 간의 연결을 만들어 줍니다. 이 경우, 호스트의 ./data/ 디렉토리가 컨테이너의 /g6 디렉토리로 마운트됩니다.

2. 두 번째 예시에서는 볼륨 이름 대신 직접 호스트의 경로(./data)를 지정하여 마운트하고 있습니다. 이것은 바인드 마운트(bind mount)라고도 합니다. 이 경우에는 볼륨을 명시적으로 정의하는 대신 호스트의 특정 경로를 컨테이너 내부의 특정 위치에 직접 연결하는 방법입니다. 위의 예시에서는 호스트의 ./data 경로가 컨테이너의 /g6 디렉토리로 바로 마운트됩니다.

3. 따라서 두 가지 방법 모두 호스트와 컨테이너 간의 데이터 공유를 가능하게 하지만, 첫 번째 방법은 볼륨을 정의하고 그것을 사용하여 마운트하는 반면, 두 번째 방법은 바로 호스트 경로를 사용하여 마운트하는 것이 차이점입니다.

4. 예제 파일에서 저는 볼륨을 사용하는 것으로 처리했지만, 직접 호스트의 경로를 마운트 했다면, 사용하시는 분이 충분한 이해를 갖고 사용하셨을 것이라고 믿습니다. 사실 Dockerfile에서도 확인할 수 있듯, 원인을 알수 없는 권한 오류가 나서 돌려 해결하기는 했습니다.

5. 제가 dockge에 대해서는 잘 모르지만, 선생님께서 말씀하신 것들을 고려했을 때, 볼륨을 사용하는 것이 더 효율적일 것 같습니다. 백업이 필요하다면 docker cp를 사용해서 백업할 수 있습니다.

6. 일반적으로 Docker Compose를 사용하여 볼륨을 정의하고 관리하는 것은 권한 문제를 해결하는 데 도움이 될 수 있습니다. 이는 Docker Compose가 볼륨을 생성하고 컨테이너에 마운트할 때 자체적으로 적절한 권한을 부여하기 때문입니다.

7. 특히, 첫 번째 방법에서는 볼륨을 명시적으로 정의하고 관리하므로 Docker가 호스트 및 컨테이너 간의 권한을 관리하는 데 도움이 됩니다. 이로 인해 보다 일관된 권한 관리가 가능하며, 어느정도 보안 및 권한 관련 문제를 방지하는 데 도움이 됩니다.

8. 다만, 이는 모든 경우에 해당하는 것은 아닙니다. 어떤 경우에는 특정 권한 문제가 발생할 수 있으며, 이에 대한 해결책은 상황에 따라 다를 수 있습니다. 하지만 일반적으로 docker-compose를 사용하여 볼륨을 관리하는 것이 권한 관련 문제를 줄일 수 있는 방법 중 하나 입니다.

9. Docker측에서 원래는 version: "3.9"와 같은 선언을 통해서 위와 같은 오류나, 특정 문법의 기능을 결정하려 했던 것 같은데, 이번에 최신 버전으로 업그레이드 하고 나서는 지원하지 않는다고 오류가 나더라구요. 이와 관련된 직접적인 오류는 아니지만, 당분간은 아마 혼란스럽지 않을 까 싶습니다.

고맙습니다.

[navystack]

@purndal, 스크린샷에 .env 파일이 보이지 않습니다. 아직 설치를 진행하지 않으신거겠지요?

저는 다음과 같은 방식으로 작업을 진행하려고 구상했습니다. :

1. 탬플릿을 사용하여 .env 파일을 생성하도록 합니다.
2. data 폴더만 관리하도록 설정합니다. (따라서 Dockerfile에서 VOLUME은 /g6/data로 선언)
3. 글과 관련된 정보는 데이터베이스에서 불러오도록 하고,
4. 나머지는 Docker 이미지를 통해 관리하도록 합니다.

메인테이너로부터 피드백이 없어서 어떻게 진행해야 할지 감이 잘 안 잡힙니다. .env 파일을 작성하지 않고, 도커 환경 변수를 주입하고 바로 런타임에서 읽어오는 것이 가능하기도 하구요.

환경 변수를 직접 관리하는 것이 .env 파일을 사용하는 것보다 더 직접적이고 유연한 방법입니다. 특히 Docker Compose를 사용하는 경우, 컨테이너의 환경 변수를 정의하고 관리하는 것이 일반적으로 더 효율적입니다.

아직은 조심스럽게 진행하고 있습니다. 기존의 관행처럼 사용자 개인이 코어를 수정하여 사용한다면 더 많은 작업이 필요할 것으로 보입니다.
또한 Docker와 관련된 고려사항이 없는 것 같아, PR을 제출하는 것도 조심스럽네요...

1. 현재, 의존성 관리를 requirements.txt로만 관리를 하고 있는데, Qemu로 컴파일하면, 컴파일이 실패할 우려가 조금 걱정되기도 합니다.
   (물론 정확히는 호스트 64비트에서 32비트를 가상화 할때 나타나는 흔한 오류이기는 합니다. 다만, 이것도 확률적으로 동일한 환경인데 컴파일이 되고 안되고 해서 골치네요)

2. 또한 개인적으로는 SQLite3를 정식 지원하고, armv6 아키텍처로 충분히 서버를 운영할 수 있을 것으로 생각해서 arm에 대해서 포기하고 싶지는 않네요 :)

3. 제가 코어에 적극적으로 PR을 할 수 없으며, 의존성 관리에 대한 선택은 npm, pnpm, yarn 등과 같은 도구와 같이 개인의 취향이 강하게 반영되기 때문에 PR을 쉽게 제출하기 어렵습니다. (PR이 무섭기도 하구요) :(

고맙습니다.

[purndal]

@navystack
. env는 숨김파일이라 보이지 않았네요 ㅎ. ls -la로 하면 다 보여요..
그리고 여기서 만들어준 docker만 arm이 설치가 가능했습니다. 다른 분들이 만들어준 것들은 설치가 안되더군요 ㅎㅎ.

우선 설치는 잘 되었습니다. 폴더 퍼미션 에러 대책도 이제 알게 되었으니 좋은 경험이었습니다.
다시 한번 좋은 서비스 해주셔서 감사합니다. 아.. 언젠가 dockerfile 궁금한 것이 있으면 질문을 드리겠습니다. ㅎ.