태그 Archives: repository

synology 에 docker 를 이용한 gitea 레포지토리 운영

gitea

git 은 기본적으로 Synology 에서 Git Server 를 제공 한다.
다만 GUI를 이용한 환경만 제공 하지 않기 때문에 어렵고 불편 하다.

그래서 Synology 서버에 docker 를 설치 하고 gitea 도커이미지를 이용해서 Container 를 띄움으로서 내부용 레포지토리를 운영 한다.
gitea go언어로 만들어져 가볍고 ssh 키 등록 및 http 연결을 잘 지원 하고 일반 사용법도 github와 비슷 하다.
ARM64 환경에서도 잘 되기 때문에 신규 사용자의 Amazon CodeCommit 이 중지된 지금 시점에서 클라우드내에 IaaS 으로 구축해 사용하기도 좋다.

 


 

  • Synology NAS 에서 docker 또는 Container Manager 를 설치 한다.(DSM 버전에 따라 패키지 명이 다를 수 있다.)

2024-12-18_165142

 

  • gitea/gitea 이미지를 다운로드 받는다.

2024-12-18_165554

 

  • 다운로드가 완료 되면 이미지를 실행해 시킨다.

2024-12-18_170015

내 경우엔 리소스를 제한하고 자동 재시작 옵션을 활성화 했다.
(gitea 는 golang 으로 만들어져 가볍지만(초기 메모리 사용량 100MB)  레포가 늘어 나면 메모리 사용량이 꾸준히 증가할 수 있다.

 

  • 다음 화면에서 연결될 포트를 선언 한다.

2024-12-18_170147

gitea 은 기본적으로 ssh, http 프로토콜을 사용한다.
DSM의 ssh 데몬과 충돌 하지 않도록 포트는 2222 으로 지정 하고 웹 포트는 3000을 사용 하도록 했다.

 

  • 파일 스테이션에서 연결할 폴더를 생성 한다.

2024-12-18_170330

Synology 에서 Container에 볼륨으로 연결될 드라이브는 docker 를 설치시 생성 되는 /docker 공유 폴더 아래에 있어야 권한 문제가 발생하지 않는다.

 

  • 스크롤을 내려서 연결할 볼륨 및 환경을 추가 한다.

2024-12-18_170421

참고로 내 Synology 의 관리자 아이디는 nas-admin 이 아니다. (쓸모 없는 =_= 공격금지)

 

  • 설정값 최종 점검 후 완료 버튼을 눌러 실행 한다.

2024-12-18_170444

 


 

  • gitea 으로 접속해 설치를 진행 한다. ( http://[Synology-Nas-IP]:3000 )

2024-12-18_173317

관리자 계정 설정의 ▶ 를 눌러서 관리자 정보를 입력 하는것을 잊지 말자.
중간에 빨간색, 파란색 칸은 Container 를 실행 할때 ssh, http 포트를 입력해야 하는 부분으로 맞추어 주어야 한다.

 

  • 테스트로 github 에 있는 레포지토리를 mirror 으로 생성 해본다.

2024-12-18_174235

2024-12-18_174248

2024-12-18_174347

미러로 생성 하는 경우 원본 에서 8시간 마다 원본에서 데이터 싱크를 해온다 ‘ㅅ’a

2024-12-19_093012

gitea 의 화면 구성은 github 과 비슷해 어렵지 않을 것이다.

 

  • 설정 변경

설치 화면에서 설정 할 수 있는 부분은 /admin 페이지에서 수정 되지 않는게 대부분 이다.
OPEN ID 차단 이나 회원 가입을 막는 부분등은 아래와 같이 /volume1/docker/gitea/gitea/conf/app.ini 설정 파일을 수정 해야 한다.

container를 사전에 정지 하고 파일 수정 한뒤에 다시 컨테이너를 시작 한다.

yum에 대해서…

CentOS 및 redhat 계열을 쓰면서 안써본사람은 없은 yum
기본적으로 yum은 배포 패키지를 설치하는 명령어 이다 ‘ㅅ’a

/etc/yum.repos.d/ 폴더에 위치하는 레포지트리에 입려된 주소를 참조하여
패키지를 검색하고 검색된 패키지를 설계도에 맞게 설치하는 역할을 한다.

그럼 레포지트리는 무엇이냐 ‘ㅅ’a
A레포지트리에서 ccc 라는 패키지를 설치 할때 서버에 설치되는 위치와
B레포지트리에서 ccc 라는 패키지를 설치할때의 위치가 틀리다.

각 레포지트리에 따라서 설치되는 패키지의 버전역시 틀려진다.
A 레포지트리에서는 버전 1.0.0 을 /usr/share/ 폴더에 설치 하지만
B 레포지트리에서는 버전 2.0.0 을 /usr/include/ 폴더에 설치 할 수 있다.

즉 레포지트리라는 것은 설계도면을 배포하는 곳 정도로 인식을 하면 비교적 정확하다고 생각된다.

 

구글신은 많은것을 알려주지만 각각의 엔지니어 특성에 따라 주로 쓰는 레포지트리는 틀릴 수 있다.
때문에 하나의 메뉴얼을 따라 하다가 안된다고 다른 메뉴얼을 따라하다가는 시스템이 엉망으로 꼬일 수 도 있다.
( 물론 두 메뉴얼이 같은 레포지트리를 이용한 메뉴얼이라면 좀 덜꼬이겠다.. )

 

yum 은 아래와 같은 사용방법으로 일반적인 사용을 한다.

 

또한 설치된 패키지의 새 설계도면에 따른 업데이트도 할수 있다.

 

또는 아래 명령어로 모든 설치패키지를 업데이트 할수도 있다 ( 심지어 커널업데이트 까지 )

 

그리고 뭔가 설치해야할 명령어(ex ftpwho)가 있다면 아래와 같은 방법으로 명령어를 포함하는 패키지를 검색을 할수도 있다.

 

최종적으로 귀찬이즘이 극에 달한 엔지니어는 yum 업데이트를 주기적으로 하는게 싫어서
아래와 같은 방법으로 자동 업데이트 데몬을 운영할수도 있다. ( 이건 아직 나도 안해봤음… )