파트 6: Hello Config - 동영상 스크립트

AI 지원 번역 - 자세히 알아보고 개선 제안하기

중요 사항

이 페이지는 스크립트만 보여줍니다. 전체 단계별 지침은 과정 자료를 참조하세요.

스크립트에 표시된 섹션 번호는 참고용으로만 제공되며 자료의 모든 섹션 번호를 포함하지 않을 수 있습니다.

환영합니다

안녕하세요, Hello Nextflow 파트 6에 다시 오신 것을 환영합니다. 이번 섹션은 설정 파일에 관한 내용이며, 이 과정의 마지막 파트입니다.

Nextflow는 특히 두 가지 측면에서 뛰어납니다. 재현성과 이식성입니다. 설정 파일은 이 중 두 번째 특징이 빛을 발하는 부분입니다. 기본 파이프라인 코드를 수정하지 않고도 Nextflow 파이프라인을 다양한 방식으로 실행하고 다양한 시스템에서 작동하도록 구성할 수 있는 능력입니다.

이러한 강력한 기능 덕분에 Nextflow 파이프라인을 다른 장소의 다른 사람들이 재사용하거나, 여러분이 접근할 수 있는 다양한 인프라에서 실행할 수 있습니다.

즉, 노트북에서 파이프라인 코드를 개발하고, 클라우드에 푸시하고, HPC에서 실행할 수 있으며, 동일한 파이프라인 코드가 모든 곳에서 실행됩니다.

이번 섹션에서는 몇 가지 주제를 다룹니다. Nextflow가 설정 파일을 처리하는 방법, 어디에서 로드하는지, 어떻게 작성하고 구성하는지, 그리고 파이프라인 자체와 설정 파일에 포함되어야 할 내용의 분리에 대해 시작하겠습니다.

그런 다음 출력 파일이 저장되는 위치를 변경하는 것과 같은 일반적인 사용 사례와 다양한 유형의 소프트웨어 패키징을 사용하거나 다양한 인프라에 작업을 제출하여 파이프라인이 다양한 인프라에서 작동하도록 하는 방법을 살펴보겠습니다.

설정 파일 계층 구조

좋습니다, 시작하겠습니다. 설정 파일을 로드할 때 Nextflow는 여러 다른 위치에서 가져올 수 있는데, 이는 좋은 점이기도 하지만 약간 위험할 수도 있습니다. 때로는 어디에서 설정 파일을 가져오는지, 어떤 순서로 로드하는지 파악하기가 조금 어려울 수 있기 때문입니다.

따라서 여기 링크를 클릭하여 Nextflow 문서로 이동하는 것을 강력히 권장합니다. 이 설정 페이지에는 설정이 로드되는 주요 위치와 중요하게는 이러한 항목이 로드되는 순서가 나열되어 있습니다.

보시다시피, Nextflow 홈 디렉토리에 설정 파일을 넣을 수 있습니다. 일반적으로 홈 디렉토리의 ".nextflow"입니다. 그리고 그 파일은 시스템에서 실행되는 모든 Nextflow 실행에 의해 항상 로드됩니다.

다음으로 찾는 위치는 파이프라인 저장소 또는 디렉토리의 루트에 있는 "nextflow.config"라는 파일입니다.

그 다음은 또 다른 "nextflow.config" 파일이지만, 이번에는 Nextflow를 실행하는 디렉토리인 실행 디렉토리에 있습니다.

마지막으로 "-c" 인수를 사용하여 명령줄에서 설정 파일 경로를 제공할 수 있으며, 여러 번 수행할 수 있습니다. 그리고 지정한 순서대로 적용됩니다.

원하는 경우 이러한 모든 위치에 설정 파일을 제공할 수 있으며, 충돌하는 설정 범위에서만 이전 것을 덮어쓰면서 반복적으로 로드됩니다.

이는 정말 강력한 시스템입니다. 합리적인 기본값을 설정한 다음 설정에 접근하면서 점점 더 구체적으로 만들 수 있기 때문입니다.

0. 준비 운동: hello-config.nf 실행

좋습니다, 이것을 닫고 Codespaces로 이동하여 시작하겠습니다. 이전과 마찬가지로 여기를 정리했습니다. 이전 results 디렉토리, Nextflow 및 work 디렉토리 등을 제거했습니다. 여전히 이러한 파일들이 남아 있어도 걱정하지 마세요. 제가 화면을 많이 확대했기 때문에 그렇지 않으면 매우 빠르게 복잡해지기 때문입니다.

디렉토리의 마지막 파일인 hello-config.nf로 작업할 것이며, 이는 이전 섹션에서 중단한 부분부터 이어집니다.

모듈 파일에서 포함되는 네 가지 다른 프로세스가 있습니다. 파이프라인 매개변수, 다양한 프로세스를 호출하고 채널을 연결하는 워크플로우 블록, 출력 채널을 게시하는 부분, 그리고 하단의 output 블록에서 해당 파일이 저장되어야 하는 위치와 복사 방법을 정의합니다.

또한 이전 장에서 이미 "nextflow.config" 파일이 있으며, 여기서 Docker를 활성화했고 오늘 이 파일을 확장할 것입니다.

이전과 마찬가지로 이 메인 스크립트의 출력 경로를 hello config로 변경했습니다. 이전에 생성한 결과와 충돌하지 않도록 하기 위해서입니다.

좋습니다, 모든 것이 예상대로 작동하는지 빠르게 확인해 보겠습니다. 터미널을 열고 nextflow run hello-config.nf를 실행합니다. Nextflow가 로드됩니다. 네 가지 다른 프로세스를 실행해야 합니다. cowpy를 사용하여 멋진 ASCII 아트를 생성한 다음 해당 디렉토리의 results 파일에 결과를 저장합니다.

여기에서 이러한 파일이 예상대로 보이는지 빠르게 확인할 수 있습니다. 그리고 확실히 거대한 칠면조가 있습니다. 좋습니다.

1.1. 기본값을 nextflow.config로 이동

이제 가장 먼저 할 일은 스크립트의 일부 항목을 설정 파일로 이동하는 것입니다.

그리고 현재 단계에서 주로 관심있는 것은 매개변수입니다. 기본값이 무엇인지 더 명확하고 사람들이 덮어쓰기 쉽도록 기본값을 설정 파일로 가져오려고 합니다.

스크립트에서 이 params 블록을 가져와 설정 파일에 넣겠습니다. 여기서 조금 주의해야 합니다. 현재 설정과 스크립트 간의 구문이 약간 다르기 때문입니다. 설정 파일은 이러한 params를 실제로 정의하는 것이 아니라 참조하기만 하므로 타입 선언을 받을 수 없습니다. 따라서 제거하겠습니다.

하지만 그 외에는 거의 동일합니다. params 블록이 있고 다양한 입력 매개변수, batch 매개변수, character 매개변수가 있습니다.

이제 스크립트로 돌아가서 이러한 기본값을 더 이상 정의할 필요가 없습니다. 이러한 값이 이제 Nextflow 설정 파일에 있기 때문입니다.

그러나 Nextflow가 해당 정보를 알고 타입 안전성 등을 계속 수행할 수 있도록 매개변수 이름과 타입은 그대로 둡니다.

좋습니다. 이러한 파일을 저장하고 모든 것이 이전과 동일하게 작동하는지 빠르게 확인합니다. 여기에는 변경 사항이 없어야 합니다. 값을 동일하게 유지했습니다. 정의된 위치만 이동했습니다.

좋습니다.

1.2. 실행별 설정 파일 사용

지금까지 파이프라인 스크립트가 있는 동일한 디렉토리에서 Nextflow를 실행했습니다. 따라서 실행 디렉토리와 파이프라인 디렉토리가 같은 것입니다.

다양한 실행 디렉토리로 다양한 설정 파일을 가질 수 있는 방법을 보여주기 위해 이제 새 하위 디렉토리를 만들겠습니다.

mkdir을 입력하고 tux-run이라고 부르겠습니다.

그런 다음 cd로 tux-run으로 디렉토리를 변경하겠습니다. 이제 작업 디렉토리가 더 이상 파이프라인 스크립트와 동일한 디렉토리에 있지 않습니다.

좋습니다, 새로운 "nextflow.config" 파일을 만들겠습니다. touch nextflow config를 입력하고 VS Code에서 열어보겠습니다. 여기 사이드바에서도 이제 이 하위 디렉토리에 있는 것을 볼 수 있습니다.

이제 최상위 nextflow.config에 있던 동일한 params 블록을 가져와 여기에 복사하고 이제 이러한 값을 변경할 수 있습니다.

먼저, 하위 디렉토리에 있기 때문에 데이터가 이제 다른 상대 경로이므로 업데이트해야 합니다. 그리고 batch를 experiment로 변경하고 character를 Turkey에서 tux로 변경하겠습니다.

이제 여기서 저장을 클릭하고 시험해 보겠습니다. 데이터와 마찬가지로 이제 스크립트로 가려면 ../를 입력해야 합니다. 따라서 Hello config입니다. 그리고 Enter를 누릅니다.

파이프라인 코드는 전혀 변경되지 않았지만 이제 두 세트의 설정이 로드되고, 실행 디렉토리 설정 파일이 파이프라인 nextflow.config에 설정된 기본값을 덮어쓰며, 다른 결과 세트를 얻어야 합니다.

확실히 여기 디렉토리 내, tux-run 내에 .nextflow 디렉토리와 work 디렉토리가 있는 것을 볼 수 있으며, 이는 실행 디렉토리에 항상 생성되기 때문입니다. 따라서 이전 실행의 work 및 results와 다릅니다.

이제 results를 보면 collected가 있고 작은 tux 캐릭터가 있습니다. 따라서 해당 매개변수가 적절하게 해석된 것을 볼 수 있습니다.

1.3. 매개변수 파일 사용

좋습니다. 이전에 로드할 수 있는 다양한 설정 파일에 대해 이야기할 때 설정을 가져올 수 있는 다른 위치 하나를 빠뜨렸습니다.

대시 대시 매개변수 이름으로 본 것처럼 명령줄에서 가져올 수 있지만 params만 포함된 YAML 또는 JSON 파일을 제공할 수도 있습니다.

설정 파일에는 다양한 유형의 범위가 있을 수 있지만, 이러한 파일은 매개변수만 포함하며, 한 번에 많은 매개변수를 제공하는 사용자 친화적인 방법이며, 파일에 작성되기 때문에 나중에 쉽게 가져올 수 있어 아마도 조금 더 재현 가능한 방법입니다.

그럼 터미널로 돌아가서 잊기 전에 디렉토리를 위로 이동하여 더 이상 하위 디렉토리에 있지 않도록 하고 여기에 있는 YAML 파일을 살펴보겠습니다. test-params.yaml이라고 합니다.

code test-params.yaml을 입력하면 이것이 일반 YAML 파일임을 알 수 있습니다. 특별한 것은 없습니다. 키가 매개변수 이름이고, YAML 형식으로 콜론이 있고 값이 있습니다.

이것은 Nextflow 코드가 아니므로 여기에 변수 같은 것을 넣을 수 없습니다. 이것들은 정적 값일 뿐입니다.

또한 JSON이 실제로 YAML로 파싱되기 때문에 test-params.json 파일도 가질 수 있으며, 이는 매우 유사하게 보입니다. 단지 데이터 형식이 다를 뿐입니다.

따라서 여기에 두 개의 다른 테스트 파일이 있고 약간 다른 변수가 있습니다.

좋습니다, 그럼 이것들을 어떻게 Nextflow에 제공할까요? 매우 간단합니다. Nextflow run hello config를 이전과 같이 수행합니다. 그리고 설정 파일의 "-c" 대신 또는 해당 기본 파일 이름을 로드하는 대신 "-params-file"을 수행합니다. 핵심 Nextflow 옵션이기 때문에 단일 하이픈입니다.

그런 다음 해당 파일의 경로를 전달합니다. "-params-file test-params.yaml"을 수행하고 제대로 로드되는지 확인하겠습니다.

좋습니다. 실행되었습니다. 이 YAML 파일에 무엇이 있었는지 빠르게 상기시켜 보겠습니다. batch가 YAML로 설정되었으므로 그렇게 호출되어야 하며 스테고사우루스가 있어야 합니다. 그럼 올라가서 results를 살펴보겠습니다. COLLECTED-yaml이 있습니다. 스테고사우루스가 있는지 보겠습니다. 환상적입니다, 모자를 쓴 스테고사우루스입니다. 우리가 원하는 것입니다.

따라서 정말 잘 작동했으며 JSON 파일도 정확히 동일합니다. 여기서 파일 확장자를 바꾸면 Nextflow가 읽는 방법을 알고 있습니다.

이 경우 JSON이라는 batch가 있어야 하고 거북이가 있어야 합니다. 살펴보겠습니다. 훌륭합니다. 제가 좋아하는 CLI 도구 중 하나입니다.

2.1. -output-dir로 출력 디렉토리 커스터마이징

좋습니다, 지금까지 주로 파이프라인에 대한 입력과 매개변수 변경을 생각했습니다. 출력은 어떨까요?

이제 params를 사용하여 하위 디렉토리를 변경했지만, 모든 파일이 여전히 results로 이동하고 있음을 알아차렸을 것입니다.

모든 파일이 게시되는 기본 디렉토리를 "-output-dir"이라는 명령줄 플래그로 변경할 수 있습니다. Nextflow run hello config를 수행한 다음 "-output-dir"을 수행하고 "custom-outdir-cli"라고 부르겠습니다. 입력할 수 없습니다. 이 파일이 어디에서 왔는지 기억할 수 있도록 하기 위해서입니다.

이것은 핵심 Nextflow 옵션이며 매우 새로운 것입니다. 최근에 추가되었으며, 이는 새로운 언어 파서 등으로 할 수 있는 일 중 하나입니다.

입력하기에는 좀 길지만 원하는 경우 "-o"라고만 할 수도 있습니다. 그럼 뒤로 가겠습니다. "-o"로 줄일 수 있으며, 이것이 좀 더 간단합니다.

좋습니다. 실행합니다. 이 시점에서 파이프라인이나 설정에서 아무것도 변경하지 않았으며, 모든 결과를 다른 최상위 디렉토리에 저장해야 합니다. 그리고 기본적으로 원하는 경로로 설정할 수 있다고 상상할 수 있습니다.

상단에 방금 도착했습니다. custom-outdir-cli가 있고 모든 파일이 동일한 하위 디렉토리 및 파일 이름으로 정확히 동일한 방식으로 구성되어 있습니다. 따라서 결과 구성 방법에 대해 너무 많이 생각하지 않고도 파이프라인이 결과를 게시하는 위치를 변경하는 정말 쉬운 방법입니다.

2.1.2. output 블록에서 하드코딩된 경로 제거

이 디렉토리를 보면 여전히 Hello Config라는 하위 디렉토리가 있는데, 이제는 좀 불필요하게 느껴집니다.

그럼 스크립트를 다시 로드하고 이제 하단의 output 블록에서 해당 하위 디렉토리를 제거할 수 있습니다. 더 이상 필요하지 않기 때문입니다. 지금 삭제할 수 있습니다. 여기에서 삭제합니다. 그리고 이것만 있으면 완전히 삭제하거나 빈 문자열로 남겨둘 수 있습니다. 나중에 다시 와서 그 자리에 다른 것을 넣을 것이기 때문에 지금은 빈 문자열로 남겨두겠습니다. 하지만 하위 디렉토리에 신경 쓰지 않는다면 거기에 path 선언을 완전히 제거하는 것이 가장 깔끔합니다.

좋습니다, 저장을 누르겠습니다. 빠르게 다시 시도해 봅시다. 실제로 기존 파일로 혼동되지 않도록 "custom-outdir-cli" 디렉토리를 제거하겠습니다. 기억하세요, 게시할 때 이미 있던 파일을 제거하지 않습니다. 새 파일을 추가할 뿐입니다. 그 명령을 다시 실행하겠습니다, custom-outdir-cli.

이제 "ls custom-outdir-cli"를 수행하면 Hello Config라는 디렉토리가 더 이상 없습니다.

2.2.1. 설정 파일에서 outputDir 설정

좋습니다, 여기 명령줄 플래그 "-o" 또는 "-output-dir"은 좋습니다. 하지만 설정에서 이에 대한 기본값을 설정하는 것은 어떨까요? 어떻게 할까요?

"nextflow.config" 파일을 열고 다른 모든 것을 닫고 제거합니다. 교육 자료 웹사이트에서 복사한 새로운 설정 옵션을 추가할 수 있습니다. outputDir이라고 합니다.

어떤 범위에도 속하지 않습니다. params나 다른 곳이 아닙니다. 최상위 레벨이며 이것을 문자열로 설정할 수 있습니다. 이제 간단하게 하드코딩된 문자열로 results가 아닌 다른 것으로 변경하는 것입니다. 하지만 Nextflow 설정 파일에 있기 때문에 여기서 조금 영리하게 변수도 포함할 수 있습니다.

그리고 여기에 이 문자열의 일부인 params 변수 params.batch를 포함했음을 볼 수 있습니다. 이것은 다른 곳에서 들어오는 변수를 재사용할 수 있다는 것을 의미합니다. 이 경우 Nextflow 파이프라인을 실행할 때 --batch를 수행하면 batch 이름이 무엇이었는지에 따라 커스텀 경로에 하위 디렉토리를 얻게 됩니다.

좋습니다, 이것을 시도하고 결과가 어떻게 보이는지 빠르게 살펴보겠습니다. Nextflow run hello config를 수행하고 --batch my_run을 수행하겠습니다. 설정이 어떻게 보였는지 상기시켜 봅시다. custom-outdir-config입니다.

tree custom-outdir-config. 그리고 batch가 my_run이라고 호출된 것을 볼 수 있습니다. 그런 다음 my_run이라는 하위 디렉토리가 있습니다. 따라서 동적 파일 경로가 작동했습니다.

그뿐만 아니라 더 이상 기본 results 디렉토리로 이동하지 않았으며 기본 디렉토리를 변경하기 위해 명령줄에 아무것도 지정할 필요가 없었습니다. 따라서 기본 outputDir의 기본값을 성공적으로 재설정했습니다.

2.2.2. batch 및 프로세스 이름이 있는 하위 디렉토리

좋습니다, 조금 더 발전시켜 보겠습니다. 설정 파일 내의 동적 변수입니다. 스크립트 자체는 어떨까요? 지금까지 여기에 이러한 경로가 있었고 이것들도 동적일 수 있습니다. 하드코딩만 하는 대신 중괄호를 넣고 동적인 것을 넣을 수 있습니다.

예를 들어 sayHello라는 프로세스가 있습니다. 프로세스의 속성인 sayHello.name을 수행할 수 있는데, 이 경우 "sayHello"일 뿐이므로 좀 지루하지만 변수입니다.

이것이 아이디어를 제공합니다. 여기에 넣고 convertToUpper.name, collectGreetings.name, collectGreetings.name 다시, 그리고 cowpy를 말할 수 있습니다.

이제 실행하면 기본 디렉토리는 여전히 custom-outdir-config가 될 것입니다. 그리고 params.batch라는 하위 디렉토리에 있을 것이지만, 그 아래의 하위 디렉토리는 프로세스 이름별로 구성되어야 합니다.

이것을 시도하고 작동하는지 보겠습니다. 혼동되지 않도록 이전 디렉토리를 제거하고 정확히 동일한 Nextflow Run 명령을 사용하겠습니다.

동일한 방식으로 실행되어야 합니다. 이전에 계산된 결과를 사용하고 조금 더 빠르게 만들기 위해 이 모든 것에 대시 resume을 사용할 수 있었습니다. 이제 tree custom-outdir-config를 수행하면 results에 있지 않고 batch 이름이 있는 기본 디렉토리에 있는 것을 볼 수 있습니다. 그리고 모든 결과가 이제 프로세스 이름을 따서 명명된 하위 디렉토리 내에 구성된 것을 볼 수 있습니다. 따라서 여기서 두 가지 다른 장소에서 동적 출력 경로를 정의하고 있습니다.

좋습니다. 마지막으로 이전에 가지고 있던 중간 폴더를 다시 추가해 보겠습니다. intermediates입니다.

또한 이 params.batch에 대해 조금 생각해 볼 수 있습니다. 파이프라인 개발자로서 그것이 하위 디렉토리에 있는 것을 정말 좋아했지만, 파이프라인의 최종 사용자가 CLI에서 "-o" 또는 -output-dir을 설정하면 이 전체 문장을 완전히 덮어쓰고 그 하위 디렉토리를 잃게 됩니다.

따라서 할 수 있는 일은 덮어쓰여지는 outputDir 설정에서 동적 경로를 빼고 덮어쓰여지지 않는 output 경로에 넣는 것입니다.

따라서 params.batch 슬래시 intermediates 슬래시 sayHello.name을 수행할 수 있으며, 이 모든 것을 Nextflow에 의해 보간되는 큰따옴표 문자열로 합니다.

이제 다른 프로세스에 이를 복사할 수 있습니다. 모든 것을 따옴표로 감싸는 것을 기억하세요. 그리고 이러한 특정 출력에서 intermediates를 제거합니다.

좋습니다. 이제 약간 더 복잡해 보이지만, 코드에서 멋지게 구성된 출력 디렉토리 구조를 정말로 구축하기 시작했음을 알 수 있습니다.

그리고 정말 좋은 점은 코드의 이러한 추가 복잡성이 CLI로 전달되지 않는다는 것입니다. 따라서 -output-dir과 어떤 batch 변수로든 명령을 실행할 수 있으며, 코드에 무엇이 있는지에 대해 너무 많이 생각하지 않고 파이프라인을 실행하는 방법에 대해서만 생각하면 됩니다. 그리고 출력 파일은 기본적으로 파이프라인을 사용하는 사람들에게 좋은, 매우 잘 구성된 방식으로 구성됩니다.

훌륭합니다. 이것을 쓰면서 실수를 했다는 것을 깨달았습니다. 누군가 나를 잡아냈는지 봅시다. collectGreetings.name이 있으니 뭔가 잘못되었네요. 그리고 네, 실수로 이것들을 중괄호에 넣는 것을 잊었습니다.

따라서 코드를 작성할 때 주의하고 무엇이 변수이고 무엇이 단순한 문자열인지 Nextflow에게 알려주세요. 왜냐하면 모든 훌륭한 컴퓨터처럼 정확히 지시한 대로 수행하고 그 이상은 하지 않을 것이기 때문입니다. 좋습니다, 그것이 해결될 것입니다.

2.3. 워크플로우 레벨에서 게시 모드 설정

여전히 좋아하지 않는 이 스크립트의 한 부분이 있는데, 그것은 mode copy를 반복해서 작성한다는 것입니다. 그리고 우리가 좋아하지 않는 한 가지가 있다면 그것은 반복하는 것입니다.

따라서 이것을 가져와서 설정으로 이동시켜 이것을 약간 정리할 수 있습니다. 실제로 전체 파이프라인에 대해 한 번에 설정할 수 있습니다. 그래서 여러 번 말할 필요가 없습니다.

설정 파일로 이동하고 여기에 workflow라는 새로운 범위가 있습니다. 그리고 중괄호를 사용하거나 점 표기법을 사용할 수 있습니다. 차이가 없습니다. 교육 자료 웹사이트는 점 표기법을 사용합니다. output이라고 말하고 혼합하고 일치시킬 수 있습니다. 따라서 mode equals copy입니다. 좋습니다.

이제 여기로 돌아가서 이것들을 삭제할 수 있습니다. 그대로 두어도 되지만, 설정은 기본적으로 여기에 작성된 내용을 덮어쓰며, 파이프라인 레벨 설정에 있고 이 두 파일이 함께 제공되므로 두 번 수행할 이유가 정말로 없습니다.

좋습니다. 스스로 확인해 보겠습니다. 실수를 한다는 것이 명백합니다. 다시 실행하고 파일을 게시하는 데 copy 모드를 올바르게 사용하고 있는지 확인해 보겠습니다. 스크립트를 다시 실행하고 이번에는 결과를 config-output-mode라는 디렉토리에 넣었습니다. 거기에서 파일이 어떻게 보이는지 확인하겠습니다.

그런 다음 "ls -l"을 수행하여 batch를 보고, 예를 들어 cowpy를 볼 수 있습니다. 그리고 보면, 네, 이것이 소프트 링크가 아닌 적절한 파일이므로 해당 설정 속성이 올바르게 적용되었습니다.

3. 소프트웨어 패키징 기술 선택

좋습니다. 지금까지 워크플로우가 실행하는 파일인 입력과 출력에 초점을 맞췄습니다. 하지만 인프라는 어떨까요? 처음에 Nextflow가 다양한 컴퓨팅 설정에서 동일한 파이프라인을 실행할 수 있게 해준다고 말했습니다. 그래서 어떻게 보일까요?

이것을 보여주기 위해 cowpy를 실행하기 위해 Docker를 사용하는 것에서 대신 Conda를 사용하여 같은 일을 하도록 전환하겠습니다.

매우 간단하게 할 수 있습니다. code "nextflow.config"로 이동합니다. 상단에서 이전 장에서 cowpy가 포함된 컨테이너를 사용할 수 있도록 docker.enabled를 정의했던 것을 기억하면,

Nextflow에게 Docker를 사용하지 말라고 지시하겠습니다. 그것을 false로 설정합니다. 그리고 Conda enabled equals true라고 하겠습니다. 따라서 Nextflow에게 Conda를 사용하라고 지시합니다.

이제 Conda를 활성화하는 것만으로는 충분하지 않습니다. Docker와 마찬가지로 Nextflow에게 필요한 소프트웨어를 어디서 얻을 수 있는지 알려주어야 합니다.

따라서 여기 모듈로 이동하여 cowpy 스크립트를 열면, 상단에 container 선언이 있는 것을 볼 수 있습니다. 그리고 컨테이너는 Docker뿐만 아니라 Singularity, Apptainer 및 다른 많은 소프트웨어 도구에서도 사용됩니다.

하지만 Conda에는 사용할 수 없으므로 "conda"라는 별도의 선언이 있으며, 단순히 "cowpy"라고 쓸 수 있습니다. 그러면 로컬 conda 환경에 따라 가장 좋은 방법을 파악하는 것은 conda 패키지 해결에 맡기게 됩니다.

또는 교육 자료 웹사이트에서 권장하는 대로 이중 콜론 표기법으로 특정 conda 채널을 정의하고, 파이프라인을 실행하는 모든 사람이 동일한 버전을 얻을 수 있도록 소프트웨어의 특정 버전을 정의하는 것이 좋은 관행입니다.

컨테이너가 이 점에서 약간 우수하다는 점에 유의하세요. Conda로 무언가를 설치할 때 여전히 해당 패키지의 모든 종속성을 파악하고 시간이 지남에 따라 변경될 수 있습니다. 이를 종속성 드리프트라고 합니다.

그러나 컨테이너는 전체 소프트웨어 종속성 스택을 완전히 잠그므로 A) 작동할 것이고, B) 재현 가능할 것이라는 확신을 더 가질 수 있습니다.

따라서 Docker나 Singularity 또는 Apptainer를 사용할 수 있다면 확실히 그것을 권장합니다.

이것의 좋은 점은 파이프라인 개발자가 작성한 모듈 파일에 이제 Container와 Conda가 모두 있으므로 이 파이프라인을 실행하는 사람에게 어떤 소프트웨어 패키징 솔루션을 사용하든 상관없다고 말하고 있는 것입니다. Docker와 Conda 모두에서 작동하며, 두 경우 모두에서 소프트웨어를 얻을 수 있는 위치입니다.

터미널을 열고 시도해 볼 수 있습니다. Nextflow run hello config --batch conda를 수행합니다. 그리고 conda로 이것이 처음 실행될 때는 해당 특정 프로세스에 도달했을 때 조금 느릴 것입니다. "conda install"을 실행해야 하기 때문입니다.

그리고 이 하나의 프로세스만을 위한 특별한 conda 환경을 만들고 있습니다. 따라서 터미널에 있는 전역 conda 환경을 사용하는 것이 아니라 그 하나의 프로세스만을 위한 환경을 만들고 있습니다. 이것은 워크플로우의 다른 프로세스 간에 종속성 충돌과 같은 문제를 피할 수 있기 때문에 좋습니다. 프로세스에 다른 버전의 Python이나 그런 것이 필요한 도구가 있는 경우, 그것은 괜찮습니다. 왜냐하면 서로 다른 conda 환경을 사용하고 있기 때문입니다.

Nextflow는 이러한 conda 환경을 로컬에 캐시하며, 경로가 어디인지 알려줍니다. work 디렉토리에 있습니다. 따라서 다음에 이 스크립트를 Conda로 실행할 때는 기존 conda 환경을 찾아서 재사용하기 때문에 훨씬 빨라질 것입니다. 하지만 처음에는 가져와서 해결하고 모든 종속성을 다운로드하고 모든 것을 설정해야 합니다.

좋습니다, 잘 실행되었습니다. 파이프라인이 현재 사용하도록 구성된 것이 무엇인지 상기해 보겠습니다. 설정 파일을 보면, 지금은 "custom-outdir-config"입니다. 해당 기본 디렉토리로 이동하면 --batch conda를 수행했습니다. 우리의 conda 하위 디렉토리가 있습니다. 따라서 작동했고 우리의 cowpy 출력이 있습니다.

따라서 conda를 가져와 로컬 시스템에 설치하고 프로세스를 실행했습니다. 그리고 최종 사용자로서 소프트웨어 관리에 대해 전혀 생각할 필요가 없었다는 것이 좋습니다. Nextflow가 모든 것을 처리했습니다. 이 시스템에서 conda를 사용해야 한다고 말했습니다. 파이프라인 개발자는 어떤 패키지가 필요한지 말했습니다. 그리고 Nextflow는 나머지를 수행했습니다. 매우 강력합니다.

실제로 다양한 기술을 혼합하여 사용할 수 있다는 점에 유의하세요. 따라서 특정 프로세스에 대해 Docker를 활성화하고, 다른 프로세스에 대해서는 conda를, 또는 일부 프로세스는 설치된 로컬 소프트웨어를 사용하도록 지정할 수 있습니다. 이것은 매우 드문 일이지만 가능하며, 예를 들어 Docker에 패키징하기 어려울 수 있는 특정 소프트웨어를 사용하는 경우 탈출구가 있습니다.

4. 실행 플랫폼 선택

그것이 소프트웨어 패키징입니다. 다른 시스템에 대한 이식성의 또 다른 부분은 작업이 실제로 실행되는 위치입니다. 현재 기본적으로 my_laptop 또는 이 Codespaces에서 실행 중이며, 이는 단일 컴퓨터입니다. 특별한 것은 없습니다. Nextflow는 최대한 작업을 병렬화하는 데 약간 영리하게 작동하고 있지만, 모두 하나의 시스템에서 실행됩니다.

이제 HPC에서 실행 중이라면 아마도 SLURM이나 PBS 또는 그와 같은 일종의 작업 스케줄러가 있을 것이며, 해당 스케줄러에 작업을 제출하면 모든 작업을 다양한 컴퓨팅 노드로 분배합니다.

실행의 또 다른 방법은 클라우드에서입니다. 아마도 AWS Batch나 Azure Cloud 또는 Google을 사용하고 있을 수 있습니다. 그리고 이들은 모두 스케줄러가 있고 작업을 제출하면 계산을 위해 다른 곳으로 제출되는 비슷한 시스템으로 작동합니다.

오래 전 내가 생물정보학을 시작했을 때, 모든 사람의 분석 실행 소프트웨어가 그들의 컴퓨팅 인프라와 매우 밀접하게 연결되어 있어 복제가 거의 불가능했습니다.

하지만 Nextflow의 이러한 설정 분리와 Nextflow가 매우 다양한 컴퓨팅 인프라 백엔드와 상호 작용하는 능력 덕분에 파이프라인 코드를 전혀 수정하지 않고 파이프라인을 가져와 전환하는 것이 매우 간단합니다.

4.1. 다른 백엔드 타겟팅

따라서 "nextflow.config" 파일로 이동하면 이제 프로세스 수준 설정을 넣을 수 있습니다. 상단에 process 범위를 넣으면 executor를 설정할 수 있으며, 여기서는 기본값인 local로 설정되어 있습니다.

이것이 프로세스 레벨이므로 다양한 프로세스를 타겟팅할 수 있다는 점에 유의하세요. 따라서 실제로 프로세스별로 실행자를 설정하고 하이브리드 실행을 할 수 있으며, 일부 작업은 Nextflow 작업이 실행되는 곳에서 로컬로 실행되고 일부는 다른 HPC에 제출되며 일부는 클라우드에 제출될 수 있습니다. 원하는 만큼 영리하게 할 수 있습니다.

이제, 이와 같은 훈련 환경에서 이것을 시연하기는 매우 어렵습니다. 제출할 HPC가 없기 때문입니다. 하지만 slurm이라고 입력하면 조금 속일 수 있으며 느낌을 얻을 수 있습니다.

그리고 이것은 SLURM에서 실행하는 데 익숙하고 SLURM 헤더가 어떻게 생겼는지 아는 사람들에게 정말 흥미롭습니다. 하지만 Nextflow run, hello config를 수행하면 존재하지 않는 클러스터에 작업을 제출하려고 할 것이기 때문에 실패할 것입니다. 따라서 sbatch가 사용 불가능하다는 오류가 발생할 것입니다.

네, 맞습니다. 그것은 slurm 클러스터에 작업을 제출하는 데 사용하는 CLI 도구입니다. 하지만 우리가 할 수 있는 일은 여기 명령으로 work 디렉토리를 살펴보고 클릭하여 해당 디렉토리를 열고 .command.run을 살펴볼 수 있습니다. 그러면 .command.run 파일의 상단에 이론적인 SLURM 클러스터에게 이 작업 제출을 처리하는 방법을 알려주는 sbatch 헤더가 있는 것을 볼 수 있습니다.

따라서 Nextflow가 영리하게 작동하고 모든 올바른 일을 하는 것을 볼 수 있습니다. 단지 제출할 클러스터가 없었을 뿐입니다.

5. 컴퓨팅 리소스 할당 제어

다양한 컴퓨팅 인프라 간에 다른 점은 무엇이 있을까요? 또 다른 것은 사용 가능한 리소스가 얼마나 있는지이며, 실제로 많은 컴퓨팅 환경에서는 작업에 필요한 CPU 수와 메모리 양을 지정해야 합니다.

다시 말하지만, Nextflow는 이것을 추상화하여 더 이상 단일 컴퓨팅 환경 유형에 특정하지 않게 하고, 여기 프로세스 수준 범위에서 입력할 수 있습니다. CPUs equals one, memory equals two gigabytes. 우리의 파이프라인은 그다지 까다롭지 않으므로 그것으로 충분해야 합니다.

이제, 여기서 이러한 숫자를 추측했지만 사용할 합리적인 리소스 양이 무엇인지 어떻게 알 수 있을까요? 많은 샘플을 가진 큰 파이프라인의 모든 다양한 프로세스를 살펴보고 리소스 사용률이 무엇이었는지 이해하는 것은 꽤 어려운 작업입니다.

따라서 이에 대한 좋은 접근법은 파이프라인이 오류 없이 실행되도록 처음에 이러한 값을 높은 숫자로 설정한 다음 Nextflow에게 사용 보고서를 생성하도록 요청하는 것입니다.

이것은 매우 쉽게 할 수 있으므로 터미널로 돌아가겠습니다. 파이프라인이 실제로 실행되도록 local로 다시 설정해야 함을 기억해야 합니다. 그리고 Nextflow run을 수행하고 -with-report 명령줄 플래그를 사용하겠습니다.

그리고 공백으로 두면 기본 파일 이름을 제공하지만, 특정 위치에 저장되도록 특정 파일 이름을 지정하겠습니다.

Enter를 누르면 파이프라인이 정상적으로 실행되지만, 완료되면 멋진 HTML 보고서를 생성할 것입니다.

따라서 여기 사이드바에 이 HTML 파일이 있습니다. 로컬에서 실행 중이라면 그냥 열면 됩니다. Codespaces에 있기 때문에 마우스 오른쪽 버튼을 클릭하고 다운로드를 클릭하여 로컬 컴퓨터로 다운로드하겠습니다. 그리고 웹 브라우저에서 쉽게 열 수 있습니다.

Nextflow는 모든 파이프라인에 대해 이와 같은 보고서를 생성할 수 있으며 정말 좋은 정보가 있습니다. 따라서 항상 이러한 것들을 저장하는 것이 좋은 습관입니다. 실행 시기, 실행 위치, 성공 여부, 사용된 매개변수, CLI 명령이 무엇인지 등을 알려줍니다.

또한 리소스 사용에 관한 이러한 그래프가 있습니다. 각 프로세스에 대해 사용된 CPU 호출의 비율을 상자 그림으로 알려줍니다. 각 프로세스에 대해 많은 작업이 있으므로 분포를 볼 수 있습니다.

여기에 cowpy와 collectGreetings 프로세스가 있는데, 단일 작업만 있었으므로 단일 라인일 뿐입니다. 그리고 CPU와 메모리 및 작업 지속 시간이 있으며 매우 빨랐습니다.

참고로 Seqera Platform을 사용하는 경우 아무것도 하지 않고도 Platform 인터페이스에 내장된 동일한 플롯을 얻습니다. 따라서 항상 이 정보를 손쉽게 얻을 수 있습니다.

좋습니다, 실제 실행에서 이 리포트를 사용하고 파이프라인이 사용하는 CPU 수와 메모리 양에 대한 감을 잡고 설정 파일로 돌아가서 해당 값을 다시 넣을 수 있습니다. 다음 번에는 아마도 그렇게 많이 요청하지 않을 것입니다. 그리고 조금 더 효율적일 수 있습니다.

이제 파이프라인 설정 파일을 구성하는 것에 대해 정말 영리해질 수 있습니다. 그리고 다시 말하지만 Seqera Platform을 사용하는 경우 전구처럼 보이는 작은 버튼을 찾으세요. 그것을 클릭하면 데이터, 실행 및 파이프라인에 특별히 맞춤화된 고도로 최적화된 설정 파일을 생성합니다. 가장 효율적인 방식으로 실행하기 위해.

하지만 지금은 실제로 Nextflow가 제공하는 기본 CPU 수가 괜찮았고 1기가바이트의 메모리만 필요하다고 말하겠습니다.

5.3. 특정 프로세스에 대한 리소스 할당 설정

이제 실제로는 파이프라인의 모든 프로세스가 동일한 요구 사항을 필요로 하는 것은 매우 드뭅니다. 리소스 측면에서 거의 필요하지 않고 매우 빠르게 실행되는 MultiQC와 같은 보고 도구가 있을 수 있습니다.

그런 다음 참조 유전체를 인덱싱하거나 일부 정렬을 수행하거나 다른 작업을 수행하는 것이 있을 수 있습니다. 무엇이든 상관없이 많은 리소스가 필요합니다. 따라서 스케줄러에 대한 이러한 다양한 작업 제출에 대해 다른 양의 리소스를 제공하려고 합니다.

이 process 범위 아래에서 특정 프로세스를 다양한 방식으로 타겟팅하는 설정을 정의할 수 있습니다.

여기서는 withName을 사용하고 있으며 레이블도 사용할 수 있으며, 이것들은 하나 또는 여러 프로세스를 타겟팅하기 위해 패턴을 사용할 수 있습니다. 여기서는 cowpy라는 이름을 가진 모든 프로세스를 2기가바이트 메모리와 2개의 CPU로 설정하고 있으며, 이것이 최상위 레벨 process보다 더 구체적인 선택자이기 때문에 이러한 경우에 덮어쓰여집니다. 따라서 파이프라인의 모든 다양한 프로세스를 정말 효율적으로 만드는 멋진 설정 파일을 여기에 구축할 수 있습니다.

5.5. 리소스 제한 추가

이제 파이프라인 개발자로서 도구를 잘 알고 있고 모든 것이 가능한 한 빠르고 잘 실행되기를 원합니다. 따라서 cowpy에 20개의 CPU를 제공하면 2개 대신 훨씬 더 빠르게 실행된다는 것을 알고 있기 때문에 이러한 일부에 대해 꽤 높은 숫자를 입력할 수 있습니다.

20개의 CPU를 사용할 수 없는 노트북이나 GitHub Actions 지속적 통합 테스트 또는 다른 시스템에서 실행할 때까지는 괜찮습니다.

이제 파이프라인을 실행하려고 하면 Nextflow가 이 작업을 어디에도 제출할 수 없다고 말하기 때문에 충돌합니다. 사용 가능한 리소스가 없습니다.

이제 그 하드 크래시를 피하기 위해 리소스 제한이라는 시스템에 특정한 조금 더 많은 설정을 추가할 수 있습니다. 그리고 그것은 이렇게 생겼습니다. 다시 process 범위 아래에 있습니다.

그리고 리소스 제한, 기본적으로 사용 가능한 상한을 지정할 수 있습니다. 여기에 맵이 있고 이 맵 내에서 메모리, CPU 및 시간을 설정할 수 있습니다.

이제 Nextflow가 프로세스에서 작업을 제출하면 요청된 것을 보고 기본적으로 그것과 그것 사이의 최소값을 수행합니다. 따라서 20개의 CPU를 요청했지만 4개만 사용 가능한 경우 4개를 요청합니다. 파이프라인이 충돌하지 않고 파이프라인 개발자가 설계한 것에 가능한 한 가깝게 사용합니다.

6. 프로필을 사용하여 사전 설정된 설정 간 전환

좋습니다. 여기 리소스 제한이 시스템별로 다를 수 있다고 말했으며, 파이프라인에 Nextflow 설정 파일이 있을 수 있고 사람들이 이것을 다양한 장소에서 사용할 것임을 알고 있습니다. 이제 모든 사람이 매번 자신의 Nextflow 설정 파일을 만들도록 강요하는 대신, 다양한 설정 사전 설정을 설정 프로필로 그룹화할 수 있습니다.

params 바로 다음에 여기서 조금 아래로 스크롤하겠습니다. 여기 설정 파일의 순서가 중요하기 때문에 설정 파일이 순차적으로 로드되므로 이전에 정의된 params를 재정의하도록 다른 모든 것 다음에 이러한 프로필을 배치하겠습니다. 그리고 교육 자료에서 이러한 프로필을 붙여넣겠습니다.

따라서 profiles라는 새로운 최상위 범위가 있습니다. 여기에 임의의 이름을 가질 수 있습니다. 따라서 my_laptop과 univ_hpc가 있습니다. 그리고 여기에서 이전에 했던 것과 동일한 설정 매개변수를 설정하는 것을 볼 수 있습니다. 이제 프로필 내에서만입니다. 따라서 my_laptop에서 실행하기 위한 local executor가 있고 HPC에서 SLURM 클러스터에 제출하고 있습니다.

로컬에서 Docker를 사용하고 HPC에서 conda를 사용하며 HPC 시스템은 훨씬 높은 리소스 제한을 가지고 있습니다.

이제 -profile CLI 옵션으로 파이프라인을 실행하여 사용하려는 프로필을 지정할 수 있습니다. my_laptop을 사용하겠습니다. 그러면 Nextflow가 해당 프로필 범위 내의 모든 설정을 적용합니다. 지금 시도할 수 있습니다. 이전과 동일한 명령입니다. Nextflow run hello config이고 대시 프로필, 핵심 Nextflow 옵션이므로 단일 대시, 대시 profile my_laptop입니다.

이제 모든 설정 옵션을 일괄 적용할 것입니다. 오, 그리고 이전에 말했듯이 프로세스 요구 사항이 4개의 CPU를 요청했지만 이 Codespaces 인스턴스에는 2개만 있다는 것을 볼 수 있습니다.

따라서 이것은 프로세스 리소스 제한을 시도하고 my_laptop 또는 이 Codespaces에 2개의 CPU만 있다고 말하는 좋은 기회입니다. 이제 다시 실행하면 해당 요구 사항을 2개로 제한하고 파이프라인이 실행되기를 바랍니다. 좋습니다.

6.2. 테스트 매개변수 프로필 생성

이러한 프로필은 인프라에 대한 설정만 있어야 하는 것은 아닙니다. params를 포함하여 여기에 모든 설정의 그룹화를 가질 수 있습니다.

따라서 사람들의 파이프라인에서 자주 볼 수 있는 또 다른 것은 일반적으로 사용자별로 제출하는 매개변수를 포함하는 test 프로필입니다. 하지만 여기서는 테스트 케이스를 실행하려고 할 때 기본적으로 다른 합리적인 기본값을 가지고 있습니다.

그리고 이것은 필수 매개변수일 수 있는 이러한 모든 것을 반드시 가서 지정할 필요가 없기 때문에 좋습니다. 대시 profile test라고만 하면 즉시 실행됩니다.

이제 주목할 점은 프로필을 두 개 이상 결합할 수도 있다는 것입니다. 여기서 profile my_laptop을 수행한 다음 test도 추가할 수 있습니다. profile을 두 번 하지 않습니다. 공백 없이 쉼표로 구분된 목록만 수행합니다. 그리고 이러한 프로필을 순서대로 적용할 것입니다. 따라서 my_laptop 프로필에서 설정을 가져온 다음 상단에 test 설정을 적용합니다.

정말 편리하며 파이프라인을 쉽게 실행할 수 있도록 여기에 많은 합리적인 기본 그룹을 설정할 수 있는 방법을 볼 수 있습니다.

6.3. nextflow config를 사용하여 해결된 설정 확인

바라건대, Nextflow 설정 해상도가 강력하다는 것을 확신시켰지만, 설정을 제공하는 약 20가지 다른 방법과 양파 껍질처럼 이러한 모든 다양한 레이어를 설명한 후 이 시점에서 조금 어지러워하더라도 탓하지 않을 것입니다.

따라서 Nextflow에 대한 최종 해결된 설정이 무엇인지 확실하지 않은 경우 "nextflow config"라는 명령이 있으며 실행할 수 있고 현재 위치에서 해결된 설정이 무엇인지 알려줍니다.

여기서 실행하면 현재 작업 디렉토리에서 "nextflow.config" 파일을 찾고 모든 다른 설정을 처리한 다음 해결된 출력을 제공합니다.

Nextflow 설정 파일은 profile CLI 옵션도 사용할 수 있습니다. 따라서 my_laptop과 test 프로필에서 해결하도록 지시하면 my_laptop 설정 옵션에서 리소스 제한도 적용되고 test에 있던 params도 설정된 것을 볼 수 있습니다.

따라서 설정 해상도가 어떻게 작동하는지 전혀 확실하지 않은 경우 탐색하는 좋은 방법입니다.

마무리

좋습니다, 그게 다입니다. 간단히 말해서 Nextflow 설정입니다. 설정으로 많은 것을 할 수 있습니다. 정말 강력합니다. 하지만 이것들은 여러분이 직면하게 될 가장 일반적인 사용 사례이며, 이러한 개념은 모든 다른 옵션에 적용됩니다.

스스로를 격려하세요. 이것이 Hello Nextflow 교육 과정의 끝이기 때문입니다. 이제 처음부터 자신만의 Nextflow 파이프라인을 작성하고, 구성하고, 실행하는 데 자신감을 가지게 되었기를 바라며, 모든 세부 사항과 주의해야 할 사항을 알고 있습니다.

설정 교육 페이지에서 시도해 볼 수 있는 퀴즈가 하나 더 있습니다. 내려가서 시도해 보고 설정에 대한 이러한 모든 부분을 이해했는지 확인하세요.

그리고 이 교육 과정 이후에 수행하면 좋을 다음 단계에 대한 간단한 마무리를 위해 마지막 동영상에 참여하세요.

함께 해주셔서 감사합니다. 잘하셨고 다음 동영상에서 뵙겠습니다.