GitLab 및 Pages 정보

GitLab 및 Pages 정보

Posted on July 6, 2021 at Safely Dysfunctional Blog by Janil Garcia in Brazilian Portuguese and translated by Eduardo Pereira Garcia

GitLab이란?

GitLab은 GitHub과 마찬가지로git 메모리 라이브러리 호스트이다. 주요 차이점은 이 프레임워크 자체가 원본(또는 Ruby로 작성된GitHub)이고 많은 위탁 관리 옵션이 있는데 그 클라우드를 포함하여 물론 당신의 전용 서버도 있다.
GitLab은 커뮤니티 버전(완전 무료)과 엔터프라이즈 버전(유료이지만 더 많은 기능에 액세스할 수 있음) 두 가지 서비스 옵션을 제공합니다.
또한 GitLab은 다양한 프로젝트 관리 및 DevOps 도구를 갖추고 있습니다.GitHub에서 이러한 서비스를 제공하기 전에GitLab CI/CD 및 GitLab 페이지를 모두 사용할 예정입니다.

GitLab CI/CD

이러한 지속적인 통합/지속적인 제공 서비스는 GitLab에서 제공합니다.프로젝트 루트 디렉토리의 YAML 파일을 사용하여 저장소에서 특정 이벤트가 발생할 때마다 수행되는 일련의 단계(예: 분기 밀어넣기 또는 결합 요청)를 설명할 수 있습니다.
Docker 이미지/컨테이너에서 시작할 명령을 실행할 환경을 지정할 수도 있습니다.또한 필요한 경우 환경 변수와 기밀 문서도 해결할 수 있다.GitLab은 이 서비스를 무료로 제공하지만 제한이 있습니다.이 실례는 메모리가 부족하여 처리 능력이 1시간만 실행될 수 있다.
자신의 runner (CI/CD를 실행할 수 있는 실례) 를 삽입할 수도 있고, 다른 GitLab runner를 설정할 수도 있습니다.응, 나는 이 블로그에 약간의 돈을 쓰고 싶지 않아. (안전하게 말하자면 기능이 좋지 않다.) 그래서 나는 무료층을 사용하기로 결정했다.
이 정보는 Hakyll 응용 프로그램은 페이지를 만들기 전에 컴파일되어야 하기 때문에 Haskell의 컴파일 과정은 상당히 비싼 과정(계산 측면에서 볼 때)이다.그럼에도 불구하고 컴파일러가 하는 많은 작업 때문에 실행 가능한 파일의 속도가 놀랍다.이 가공 원가는 곧 토론할 것이다.

GitLab 페이지

예, GitLab Pages은 정적 페이지를 호스팅하는 GitLab 서비스입니다.누가 위탁 관리할 정적 페이지가 있는지 알아맞혀 보세요.이 녀석(가니엘이 자신을 가리키며). -재미있다, 형제-
GitLab Pages는 GitLab CI/CD에 통합되므로 모든 SSG(Static Site Generator) 1을 통해 페이지를 생성하고 웹 서버에 파일을 배치할 수 있습니다.
이것은 특히 나의 프로젝트 문서나 블로그에 매우 유용하다.
가장 중요한 단계는 프로젝트의 이름을 사이트의 숙주로 선택하는 것이다. 이것은 불가사의해 보인다.GitLab의 사용자 이름은 다음과 같이 페이지에 매핑되는 janilcgarcia입니다.

consider $user_name = janilcgarcia and $project_name = blog

프로젝트 이름이 $user name 모드를 따르는 경우

gitlab.io (이 예는 janilcgarcia.gitlab.io) 이고, 이 페이지는 janilcgarcia에 있습니다.gitlab.이오.

프로젝트 이름이 $user name에서 호스팅하는 프로젝트 이름과 다른 경우gitlab.io/$project name(즉, janilcgarcia.gitlab.io/blog).

또 하나의 추가 세부 사항, GitLab 지원 그룹의 개념은 기본적인 특성이다. 특히 관련 프로젝트와 인원에 대한 것이다.
각 그룹은 다음 표 $group.gitlab.io(내 예에서는 https://safelydysfunctional.gitlab.io)과 같이 정적 페이지를 호스팅할 도메인을 받습니다.이것을 사용하면 당신은 합법적인 도메인 이름을 사용하여 당신의 사이트에 서비스를 제공할 수 있습니다.그룹 맵의 작업 원리는 앞에서 설명한 것과 같습니다.
GitLab Pages 웹 사이트에서는 필요한 도구를 사용하여 자신의 페이지를 적절하게 구성할 수 있지만 다음과 같은 생각이 듭니다.

# You start setting the image for the runner
image: docker/base/image

# Then you define the steps to generate the pages
pages:
  # on `script` you put the steps necessary to build the page
  script:
    - ssg compile -o public/

  # on artifacts you specify files that should be kept after the execution
  # the pages MUST be on the public/ directory in project root
  artifacts:
    paths:
      - public

  # with `only` you can specify which branches trigger this action
  only:
    - master

하킬 및 CI/CD

내가 Haskell 컴파일하는 데 시간이 걸린다고 말한 거 기억나?좋습니다. Haskell docker 이미지를 가져오고 프로젝트를 컴파일하고 바이너리 파일을 사용해서 정적 페이지를 만들면 작업이 실패합니다.한 시간 후에 나는 가장 어려운 방식으로 이 점을 배웠다.
사이트가 실행 중이니까 내가 다른 경로를 찾은 거 알지?
알겠습니다. 한동안 미리 컴파일된 바이너리 파일로 그림을 만들었기 때문에 제 PC에서 컴파일러를 실행할 수 있습니다. 컴파일러는 더욱 강한 처리 능력을 가지고 Docker Hub에 업로드됩니다.
이 방법은 바이너리 파일이 자주 바뀌지 않기 때문에 코드의 일부 내용을 변경할 때만 변경됩니다.
그러나 내 컴퓨터에 이미지를 만들어 Docker Hub에 보내야 하고 코드를 변경할 때마다 이렇게 해야 한다는 단점이 있다.하지만 나는 하스켈의 사람들이 다른 방법을 사용하고 있다는 것을 안다, 닉스.

닉스

Nix는 NixOS 패키지 관리자이지만 다른 버전에서도 실행됩니다. (나는 그것이 심지어 MacOS에서도 실행될 것이라고 믿습니다.)Nix의 가장 큰 차이점은 가방을 특정 디렉터리에 있는 시스템과 분리한 다음 필요할 때 호환되는 방식으로 연결한다는 것이다.
이것은 시스템에서 같은 소프트웨어 패키지의 여러 버전을 제공할 수 있도록 한다.Nix는 이러한 통합을 위해 선언적 언어(순수 함수식)를 사용합니다.따라서 모든 운영체제 환경은 변할 수 없다. 소프트웨어 패키지를 설치하면 하나의 함수를 응용하여 이 환경을 소프트웨어 패키지가 있는 새로운 상태로 업데이트할 수 있다.
하스켈의 완벽한 동반자로서 운영체제 자체에도 부작용이 없다.
보기 좋죠?그러나 한 가지 약점은 문서가 부족해서 패키지 메이커가 어떻게 일을 하는지 도와주고 이해하기 어렵다는 것이다. 이것은 쉬운 임무가 아니다.
다행히도, 나는 교과서 한 권을 찾았고, 나에게 답을 주었다.
https://cah6.github.io/technology/nix-haskell-1/
긴 시간 동안의 투쟁과 심도 있는 검색을 통해 저는 3개의 파일 저장소 구성(blog.nix, default.nix 및 shell.nix)으로 끝냈습니다.blog.nix은 cabal을 사용하는 프로젝트를 기반으로 한 새로운 패키지를 설명합니다

{ mkDerivation, base, binary, bytestring, data-default, directory
, filepath, fsnotify, hakyll, http-types, lib, pandoc, pandoc-types
, process, tagsoup, text, wai, wai-app-static, wai-extra, warp
, pythonPackages
}:
mkDerivation {
  pname = "blog";
  version = "0.1.0.0";
  src = ./.;
  isLibrary = false;
  isExecutable = true;
  executableHaskellDepends = [
    base binary bytestring data-default directory filepath fsnotify
    hakyll http-types pandoc pandoc-types process tagsoup text wai
    wai-app-static wai-extra warp
  ];
  executableSystemDepends = [ pythonPackages.pygments ];
  license = lib.licenses.gpl3;
  hydraPlatforms = lib.platforms.none;
}

default.nix은 프로젝트를 어떻게 컴파일하는지 설명하고 컴파일링이 반드시 있어야 하는 환경을 정의했다.

let
  pinnedPkgs = import ./pkgs-from-json.nix { json = ./release-21.05.json; };
in
pinnedPkgs.pkgs.haskellPackages.callPackage ./blog.nix { }

마지막으로, shell.nix은 닉스셸이 컴파일 환경에서 시작할 수 있음을 설명했다.필요하면 hoogle과haskell 언어 서버를 입력할 수 있습니다.

{ }:
(import ./default.nix).env

지금 만약 네가 이것이 어떻게 된 일인지 알고 싶다면, 나는 사람을 잘못 물었다.나는 이것이 매우 효과가 있다는 것을 안다. 단지 이것뿐이다.
프로젝트의 컴파일 환경에 pygments을 설치하는 것이 어떻게 실현되는지 알아야 한다.이를 위해 나는 파일 blog.nix을 수정하고 속성 executableSystemDepends을 추가해야 한다. 그 중에서 pythonPackages.pygments, 즉 Nix의pygments 패키지 이름을 포함한다.
나는 이것이 이 소프트웨어 패키지를 설치하는 정확한 위치가 아닐 수도 있다고 믿는다. (그러나 이것은 틀림없이 프로젝트 의존일 것이다.)아마도 나는 그것을 shell.nix에 삽입해야 할 것 같지만, 이 모든 것을 알기 전에, 그것은 계속 존재할 것이다.가장 중요한 것은 그것이 원래의 모양대로 작동하기 때문에 우리는 가능한 한 고장이 없는 물건을 수리하지 말아야 한다.

GitLab의 닉스

Nix에서 기능 환경을 만들면 GitLab CI/CD에서 쉽게 사용할 수 있습니다.
이것이 바로 내가 필요로 하는 것이다.

image: nixos/nix

pages:
  before_script:
    - nix-build default.nix

  script:
    - nix-shell --run 'result/bin/site build'

  artifacts:
    paths:
      - public

  only:
    - master

간단하지 않습니까?Docker Hub에서 사용할 수 있는 nixos/nix을 사용합니다. (아주 작고 패키지 관리자만 포함됩니다. 심지어 bash은 없는 것 같습니다.) 설명으로 사이트 생성기를 default.nix으로 컴파일하여 사이트를 생성한 후, 그 결과를 공공 디렉터리에 저장하고 GitLab 페이지에서 수집하여 웹에 들어갑니다.

결론

가장 어려운 것은 닉스를 일하게 하는 것이다.GitLab CI 및 GitLab 페이지는 매우 간단하고 유연합니다.이 글에는 하킬의 전설이 첨부되어 있어, 지금!!!허허

"That's all folks!"

More about SSGs   ↩