Docker ko KR

도커

ASF는 docker 컨테이너 형태로도 제공됩니다. 저희의 docker 패키지는 현재 **ghcr.io**와 **Docker Hub**에서 이용 가능합니다.

ASF를 Docker 컨테이너에서 실행하는 것은 **고급 설정(advanced setup)**으로 간주되며, 대다수의 사용자에게는 필요하지 않고, 일반적으로 컨테이너를 사용하지 않는 설정에 비해 별다른 이점이 없다는 점을 유의해야 합니다. ASF를 서비스로 실행하기 위한 방법으로(예: OS와 함께 자동 시작되도록 하기 위해) Docker를 고려하고 계시다면, 대신 관리(management) 섹션을 읽어보시고 적절한 systemd 서비스를 설정하시는 것을 고려해보세요. 이는 Docker 컨테이너에서 ASF를 실행하는 것보다 거의 항상 더 나은 방법입니다.

Docker 컨테이너에서 ASF를 실행하면 보통 직접 마주하고 해결해야 하는 여러 새로운 문제와 이슈가 발생합니다. 이러한 이유로, 이미 Docker에 대한 지식이 있고 내부 동작 방식을 이해하는 데 별도의 도움이 필요하지 않은 경우가 아니라면 이를 피하시길 강력히 권장드립니다. Docker 내부 동작에 대해서는 ASF 위키에서 자세히 다루지 않습니다. 이 섹션은 매우 복잡한 구성의 정당한 사용 사례를 위한 것으로, 예를 들어 ASF가 systemd 서비스에서 기본 제공하는 표준 샌드박싱(이미 매우 고급 보안 메커니즘을 통해 우수한 프로세스 격리를 보장함)을 넘어서는 고급 네트워킹이나 보안이 필요한 경우입니다. 이런 소수의 사용자를 위해, 여기서는 ASF의 Docker 호환성에 관한 개념을 좀 더 자세히 설명합니다. 다만 이 부분에 한해서이며, ASF와 함께 Docker를 사용하기로 결정했다면 사용자 스스로 충분한 Docker 지식을 갖추고 있다고 가정합니다.

---

태그

ASF는 여러 종류의 **태그(tags)**를 통해 제공됩니다:

main

main 브랜치의 최신 커밋으로 빌드된 ASF의 범용 빌드로, 저희 CI 파이프라인에서 최신 아티팩트를 직접 가져오는 것과 동일하게 동작합니다. 개발 목적으로 개발자 및 고급 사용자를 위해 제공되는, 버그가 가장 많을 수 있는 수준의 소프트웨어입니다. 이 이미지는 GitHub main 브랜치에 커밋이 있을 때마다 업데이트되므로, 매우 잦은 변경(그리고 일부 기능이 정상 작동하지 않는 상황)이 있을 수 있습니다. 저희 릴리스 주기에서 설명한 것처럼, 안정성이나 테스트 완료가 반드시 보장되지는 않는 ASF 프로젝트의 현재 상태를 나타내기 위한 것입니다. 이 태그는 어떠한 프로덕션 환경에서도 사용해서는 안 됩니다. 해당 커밋이 겪고 있는 문제를 실제로 수정했는지 확인하고자 할 때, 그 커밋이 포함된 pre-release조차 기다리지 않고 검증할 수 있어 유용합니다.

released

pre-release를 포함하여 항상 최신 릴리스된 ASF 버전을 가리키는 ASF의 범용 빌드입니다. main 태그와 달리, 이 이미지는 새로운 GitHub 태그가 푸시될 때마다 업데이트됩니다. 안정적이면서도 새로운, 최첨단에 있기를 좋아하는 고급 사용자를 위한 것입니다. 실제로는 pull 시점에서 가장 최신의 A.B.C.D 릴리스를 가리키는 롤링 태그와 동일하게 동작합니다. 이 태그를 사용하는 것은 저희 **pre-release**를 사용하는 것과 동일하다는 점에 유의하세요.

안정 버전

항상 최신 stable ASF 버전을 가리키는 ASF의 범용 빌드입니다. released 태그와 달리, 이 이미지는 새로운 ASF stable 버전이 나올 때 업데이트됩니다. 위에서 언급한 released 태그의 stable 버전을 찾는 사용자에게 권장됩니다.

latest

항상 최신 stable ASF 버전을 가리키는 OS별 ASF 빌드입니다. 다른 태그들과 비교했을 때, 이 태그만이 유일하게 ASF 자동 업데이트를 포함합니다. 이 태그의 목적은 자체 업데이트가 가능한 OS별 ASF 빌드를 실행할 수 있는, 무난한 기본 Docker 컨테이너를 제공하는 것입니다. 이 때문에 가능한만큼 자주 업데이트 될 필요가 없습니다. 포함된 ASF 버전은 필요하다면 스스로 업데이트될 수 있습니다.

물론 UpdatePeriod는 안전하게 끌 수 있지만(0으로 설정), 이 경우에는 대신 stable 릴리스를 사용하는 것이 좋습니다. 마찬가지로, 원한다면 기본 UpdateChannel을 수정하여 pre-release를 추적하도록 할 수도 있습니다.

latest 이미지는 자동 업데이트 기능이 있기 때문에, .NET 런타임과 generic ASF 버전을 포함하는 다른 모든 태그와 달리, OS별 linux ASF 버전과 함께 기본(bare) OS만 포함합니다. 이는 업데이트된 새 ASF 버전이 이미지가 빌드될 때 사용된 런타임보다 더 새로운 런타임을 요구할 수 있기 때문입니다. 그렇지 않으면 이미지를 처음부터 다시 빌드해야 하며, 이는 원래 의도한 사용 목적을 무의미하게 만듭니다.

A.B.C.D

태그와 일치하는 고정된 ASF 버전을 가리키는 ASF의 범용 빌드입니다. 위의 태그들과 비교했을 때, 이 태그는 완전히 고정되어 있어 한 번 게시된 이미지는 이후 업데이트되지 않습니다. 최초 릴리스 후 한번도 건드리지 않은 GitHub 릴리스와 유사하게 동작하고, 안정적이고 동결된 환경을 보장합니다. 일반적으로 특정 ASF 릴리스를 사용하고 빌드 결과가 항상 동일하기를 기대하는 경우(예: ASF 버전을 직접 관리하고자 하는 경우) 이 태그를 사용해야 합니다.

---

어떤 태그가 최선입니까?

찾고 있는 것에 따라 다릅니다. 대부분의 사용자에게 latest 태그가 최선입니다. 이는 서비스로 되어있는 특별한 도커 컨테이너에 담겨있을 뿐 데스크탑 ASF가 제공하는 것을 정확하게 동일하게 제공합니다. 다만, 이것이 반드시 Docker를 사용하는 올바른 방식은 아닙니다 - 일반적으로는 컨테이너를 계속 실행하는 것이 아니라 다시 빌드하는 것이 기대되며, 이 경우에는 Docker 가이드라인을 따르는 stable이나 released 태그를 사용하는 것이 좋습니다. 마지막으로, 특정 고정 버전의 ASF를 실행하고 싶다면 당연히 A.B.C.D 릴리스가 찾고 있는 것에 해당합니다.

main 빌드는 저희가 ASF 프로젝트의 현재 상태를 표시하기 위한 용도이므로, 일반적으로 사용을 권장하지 않습니다. 그 상태는 어떤것도 정상작동을 보장하지 않지만, ASF 개발에 관심이 있다면 시도해보는 것도 좋습니다.

---

아키텍쳐

ASF Docker 이미지는 현재 linux 플랫폼에서 x64, arm, arm64 3가지 아키텍처를 대상으로 빌드됩니다. 더 많은 정보는 호환성 항목을 참고하십시오.

저희 태그는 멀티 플랫폼 매니페스트를 사용하므로, 이미지를 pull할 때 사용자의 기기에 설치된 Docker가 해당 플랫폼에 맞는 이미지를 자동으로 선택합니다. 혹시라도 현재 실행 중인 플랫폼과 다른 특정 플랫폼용 이미지를 pull하고 싶다면, docker run과 같은 적절한 docker 명령어에서 --platform 스위치를 사용하면 됩니다. 자세한 내용은 **이미지 매니페스트(image manifest)**에 관한 docker 문서를 참고하세요.

---

사용법

완전한 참조는 **도커 공식 문서**를 참고하시고, 이 가이드에서는 간단한 사용법만 다룹니다. 더 깊이 공부하는 것도 좋습니다.

안녕하세요 ASF!

먼저 도커가 정상적으로 작동하는지 확인해야합니다. 이것이 ASF의 "Hello World!" 입니다.

docker run -it --name asf --pull always --rm justarchi/archisteamfarm

docker run 으로 당신의 새로운 ASF 도커 컨테이너를 생성하고 전경에서 실행되도록 합니다(-it). --pull always는 최신 이미지가 먼저 pull되도록 보장하며, --rm은 지금은 단순히 정상 작동 여부를 테스트하는 것이므로 컨테이너가 중지되면 자동으로 삭제되도록 보장합니다.

모든것이 성공적으로 끝나면, 모든 레이어를 당기고 컨테이너를 시작한 뒤 ASF가 정상적으로 시작해서 정의된 봇이 없다고 알리고 있음을 알게 됩니다. ASF가 도커에서 정상적으로 작동하고 있습니다. CTRL+C를 누르면 ASF 프로세스가 종료되며, 이에 따라 컨테이너도 함께 종료됩니다.

명령어를 자세히 봤다면 태그를 선언하지 않았음을 알게 되었을 겁니다. 태그는 자동으로 기본값인 latest 가 됩니다. latest가 아닌 다른 태그(예: released)를 사용하고 싶다면, 이를 명시적으로 지정해야 합니다:

docker run -it --name asf --pull always --rm justarchi/archisteamfarm:released

---

볼륨 사용

ASF를 도커 컨테이너에서 사용하고 있다면 프로그램 자체를 환경설정할 필요가 있습니다. 다양한 방법으로 할 수 있지만, 추천하는 것은 로컬 기기에 ASF config 디렉토리를 만들어서 ASF 도커 컨테이너에 공유 볼륨으로 마운트 하는 것입니다.

예를 들어, 당신의 ASF 환경설정 폴더가 /home/archi/ASF/config 디렉토리에 있다고 가정합니다. 이 디렉토리는 핵심 ASF.json과 실행하려는 봇이 담겨 있습니다. 이제 할일은 단순히 이 디렉토리를 도커 컨테이너에 공유볼륨으로 붙이는 것입니다. ASF는 여기에 환경설정 디렉토리(/app/config)가 있다고 생각합니다.

docker run -it -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm

그러면 끝입니다. 이제 ASF 도커 컨테이너는 로컬 기기에 있는 공유 디렉토리를 읽기-쓰기 모드로 사용하고, 이는 ASF를 설정하는데 필요한 전부입니다. 마찬가지 방식으로, /app/logs나 /app/plugins처럼 ASF와 공유하고 싶은 다른 볼륨도 마운트할 수 있습니다.

물론, 이는 우리가 원하는 바를 달성하기 위한 하나의 방법일뿐이고, 자신만의 Dockerfile을 만들어서 환경설정 파일을 ASF 도커 컨테이너 안의 /app/config 디렉토리로 복사하는 등 당신이 하려는 것을 막을수 있는 것은 없습니다. 이 가이드에서는 기본적인 것만을 다룹니다.

볼륨 권한

ASF 컨테이너는 기본적으로 root 사용자로 초기화되어 내부 권한 관련 작업을 처리할 수 있으며, 이후 메인 프로세스의 나머지 부분에서는 asf(UID 1000) 사용자로 전환됩니다. 이는 대다수 사용자에게는 문제가 없지만, 공유 볼륨에는 영향을 미칩니다. 새로 생성되는 파일은 일반적으로 asf 사용자 소유가 되는데, 공유 볼륨에 다른 사용자를 지정하고 싶다면 원하지 않는 상황일 수 있습니다.

ASF가 실행되는 사용자를 변경하는 방법에는 두 가지가 있습니다. 첫 번째, 권장되는 방법은 실행하고자 하는 대상 UID를 ASF_UID 환경 변수로 지정하는 것입니다. 두 번째, 대안적인 방법은 docker가 직접 지원하는 --user **플래그**를 전달하는 것입니다.

예를 들어 id -u 명령어로 본인의 uid를 확인한 뒤, 위에서 설명한 대로 지정하면 됩니다. 예를 들어, 대상 사용자의 uid가 1001인 경우:

docker run -it -e ASF_UID=1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm

# Alternatively, if you understand the limitations below
docker run -it -u 1001 -v /home/archi/ASF/config:/app/config --name asf --pull always justarchi/archisteamfarm

ASF_UID와 --user 플래그의 차이는 미묘하지만 중요합니다. ASF_UID는 ASF가 지원하는 커스텀 메커니즘으로, 이 경우 docker 컨테이너는 여전히 root로 시작하며, 이후 ASF 시작 스크립트가 ASF_UID 권한으로 메인 바이너리를 실행합니다. --user 플래그를 사용하면, ASF 시작 스크립트를 포함한 전체 프로세스가 지정된 사용자 권한으로 시작됩니다. 첫 번째 방법을 사용하면 ASF 시작 스크립트가 권한 등을 자동으로 처리해주어, 사용자가 유발했을 수 있는 일부 일반적인 문제를 해결해줍니다. 예를 들어 /app과 /asf 디렉토리가 실제로 ASF_UID 소유가 되도록 보장합니다. 두 번째 방식에서는 root로 실행되지 않기 때문에 이러한 처리를 할 수 없으며, 사용자가 미리 직접 모두 처리해야 합니다.

--user 플래그를 사용하기로 했다면, 기본값인 1000에서 새로 지정한 커스텀 사용자로 모든 ASF 파일의 소유권을 변경해야 합니다. 아래 명령어를 실행하여 이를 수행할 수 있습니다:

# Execute only if you're not using ASF_UID
docker exec -u root asf_container_name chown -hR 1001 /app /asf

이 작업은 docker run으로 컨테이너를 생성한 후 한 번만 수행하면 되며, --user docker 플래그를 통해 커스텀 사용자를 사용하기로 한 경우에만 필요합니다. 또한 위 명령어의 1001 인수를 실제로 ASF를 실행하고자 하는 UID로 변경하는 것을 잊지 마세요.

Volume with SELinux

RHEL 계열 배포판 등에서 기본값인 enforced 상태로 SELinux를 사용 중이라면, 볼륨을 마운트할 때 :Z 옵션을 추가해야 합니다. 그러면 해당 볼륨에 올바른 SELinux 컨텍스트가 설정됩니다.

docker run -it -v /home/archi/ASF/config:/app/config:Z --name asf --pull always justarchi/archisteamfarm

이를 통해 ASF가 docker 컨테이너 내부에서 해당 볼륨을 대상으로 파일을 생성할 수 있게 됩니다.

---

다중 인스턴스 동기화

management 섹션에 명시된 대로, ASF는 다중 인스턴스 동기화 기능을 지원합니다. ASF를 docker 컨테이너에서 실행할 때, 여러 개의 ASF 컨테이너를 실행 중이고 이들을 서로 동기화하고 싶다면 선택적으로 이 과정에 "참여"할 수 있습니다.

기본적으로 docker 컨테이너 내에서 실행되는 각 ASF는 독립적(standalone)이며, 이는 동기화가 이루어지지 않는다는 의미입니다. 인스턴스 간 동기화를 활성화하려면, 동기화하려는 모든 ASF 컨테이너의 /tmp/ASF 경로를 docker 호스트의 하나의 공유 경로에 읽기-쓰기 모드로 바인드해야 합니다. 이는 위에서 설명한 볼륨 바인딩과 정확히 동일한 방식으로 이루어지며, 경로만 다를 뿐입니다:

mkdir -p /tmp/ASF-g1
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/archi/ASF/config:/app/config --name asf1 --pull always justarchi/archisteamfarm
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/john/ASF/config:/app/config --name asf2 --pull always justarchi/archisteamfarm
# 이제 모든 ASF 컨테이너가 서로 동기화됩니다.

ASF의 /tmp/ASF 디렉토리도 사용자 기기의 임시 /tmp 디렉토리에 바인드할 것을 권장하지만, 물론 사용 목적에 맞는 다른 경로를 자유롭게 선택하셔도 됩니다. 동기화되기를 원하는 각 ASF 컨테이너는 동일한 동기화 프로세스에 참여하는 다른 컨테이너들과 /tmp/ASF 디렉토리를 공유해야 합니다.

위 예시에서 짐작하셨겠지만, 서로 다른 docker 호스트 경로를 ASF의 /tmp/ASF에 바인드함으로써 두 개 이상의 "동기화 그룹"을 만드는 것도 가능합니다.

/tmp/ASF 마운트는 완전히 선택 사항이며, 두 개 이상의 ASF 컨테이너를 명시적으로 동기화하고 싶은 경우가 아니라면 실제로 권장하지 않습니다. ASF 컨테이너를 하나만 실행할 계획이라면 /tmp/ASF를 마운트해도 전혀 이점이 없으며, 오히려 마운트하지 않았다면 피할 수 있었던 문제가 발생할 수 있으므로 단일 컨테이너 사용 시에는 마운트하지 않는 것을 권장합니다.

---

명령줄 인자

ASF는 환경변수를 통해 명령줄 인자 를 도커 컨테이너로 넘겨줄 수 있습니다. 지원하는 스위치를 위해서는 특별한 환경변수를, 그 외에는 ASF_ARGS 를 사용해야 합니다. docker run 에 -e 스위치를 붙이면 됩니다. 다음은 예시입니다.

docker run -it -e "ASF_CRYPTKEY=MyPassword" -e "ASF_ARGS=--no-config-migrate" --name asf --pull always justarchi/archisteamfarm

이렇게 하면 --cryptkey 인자 뿐 아니라 다른 인자들도 도커 컨테이너 내부에서 실행되는 ASF 프로세스로 전달할 것입니다. 물론 고급 사용자라면 ENTRYPOINT를 수정하거나 CMD를 추가하여 직접 커스텀 인수를 전달할 수도 있습니다.

커스텀 암호화 키나 다른 고급 옵션을 제공하고 싶은 경우가 아니라면, 일반적으로 특별한 환경 변수를 포함할 필요가 없습니다. 저희 docker 컨테이너는 이미 무난하고 기대되는 기본 옵션인 --no-restart로 실행되도록 구성되어 있어, 해당 플래그를 ASF_ARGS에 명시적으로 지정할 필요가 없기 때문입니다.

---

IPC

IPC **전역 설정 속성**의 기본값을 변경하지 않았다면, 이는 이미 활성화되어 있습니다. 다만, Docker 컨테이너에서 IPC가 작동하려면 두 가지를 추가로 해야 합니다. 첫째, IPCPassword를 사용하거나, 이를 사용하지 않고도 외부에서 연결할 수 있도록 커스텀 IPC.config에서 기본 KnownNetworks를 수정해야 합니다. 정말로 무엇을 하는지 정확히 알고 있는 경우가 아니라면, 그냥 IPCPassword를 사용하세요. 둘째, docker는 루프백 인터페이스로 외부 트래픽을 라우팅할 수 없으므로, 기본 수신 대기 주소인 localhost를 수정해야 합니다. 모든 인터페이스를 리슨하는 설정값의 예시입니다. http://*:1242. 물론 로컬 LAN이나 VPN 네트워크 같은 더 제한적인 바인딩을 사용할 수도 있지만, 외부에서 라우팅 가능해야 합니다. localhost는 게스트 기기안에서만 라우팅하므로 이것이 불가능합니다.

위와 같이 하려면, 아래와 같은 **사용자 설정 IPC**를 사용해야 합니다.

{
    "Kestrel": {
        "Endpoints": {
            "HTTP": {
                "Url": "http://*:1242"
            }
        }
    }
}

IPC를 루프백이 아닌 인터페이스에 설정하고 나면, -P 나 -p 스위치를 사용해서 도커에게 ASF의 1242/tcp 포트를 알려주어야 합니다.

예를 들어, 이 명령어는 ASF의 IPC 인터페이스를 호스트 기기에 열 것입니다.

docker run -it -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 --name asf --pull always justarchi/archisteamfarm

모든 것을 정확하게 설정했다면 위의 docker run 명령어는 호스트 기기의 IPC 인터페이스가 게스트 기기로 리다이렉트된 표준 localhost:1242 라우트에서동작하도록 할 것입니다. 이 라우트를 더 많이 노출하지 않음을 알아 두십시오. 연결은 오직 도커 호스트안에서만 이루어지고 안전하게 유지됩니다. 물론, 무엇을 하는지 정확히 알고 적절한 보안 조치를 취한다면 경로를 더 개방할 수도 있습니다.

---

완전한 예제

위의 지식을 모두 합치면 완전한 설치 예시는 다음과 같습니다.

docker run -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 -v /home/archi/ASF/config:/app/config -v /home/archi/ASF/plugins:/app/plugins --name asf --pull always --restart unless-stopped justarchi/archisteamfarm

이는 단일 ASF 컨테이너를 사용하고, 모든 ASF config 파일이 /home/archi/ASF/config에 있다고 가정한 것입니다. config 경로는 사용자 기기 환경에 맞는 경로로 수정해야 합니다. ASF에 커스텀 플러그인을 제공하는 것도 가능하며, 이는 /home/archi/ASF/plugins에 넣으면 됩니다. 다음과 같은 IPC.config 를 환경설정 디렉토리에 넣기로 결정했다면 추가로 IPC 사용도 가능합니다.

{
    "Kestrel": {
        "Endpoints": {
            "HTTP": {
                "Url": "http://*:1242"
            }
        }
    }
}

다음 docker compose config를 사용하면 위의 docker run 명령어와 동일한 효과를 얻을 수 있습니다:

version: "3.8"
services:
  asf:
    image: justarchi/archisteamfarm
    container_name: asf
    restart: unless-stopped
    ports:
      - "127.0.0.1:1242:1242"
      - "[::1]:1242:1242"
    volumes:
      - /home/archi/ASF/config:/app/config
      - /home/archi/ASF/plugins:/app/plugins

앞서 다룬 내용 외에, 위 두 예시 모두에 --restart unless-stopped를 추가하여 기기가 재시작된 후 이 컨테이너가 자동으로 시작되도록 했습니다. 필요에 맞게 자유롭게 제거하거나 변경하셔도 됩니다.

---

프로 팁

ASF 도커 컨테이너가 준비되어있다면 docker run를 매번 실행할 필요가 없습니다. docker stop asf와 docker start asf로 ASF 도커 컨테이너를 쉽게 멈추고 시작할 수 있습니다. latest 태그를 사용하지 않는 경우, 최신 ASF를 사용하려면 여전히 docker stop, docker rm을 실행한 후 docker run을 다시 실행해야 한다는 점에 유의하세요. 이는 매 버전마다 새로운 ASF 도커 이미지로부터 다시 빌드해야 하기 때문입니다. latest 태그에서는 ASF가 자체 자동 업데이트 기능을 포함하고 있으므로, 최신 ASF를 사용하기 위해 이미지를 다시 빌드할 필요는 없습니다 (다만 최신 .NET 런타임 종속성 및 기반 OS를 사용하기 위해, 특히 ASF 주요 버전 업데이트를 건너뛰어 넘어가는 경우 필요할 수 있으므로 가끔씩 다시 빌드하는 것도 좋은 방법입니다).

위에서 암시하였듯이, latest 가 아닌 ASF 태그는 스스로 자동 업데이트하지 않습니다. 즉, 당신이 최신의 justarchi/archisteamfarm 저장소를 사용할 주체입니다. 보통 앱이 실행중에는 코드를 건드려서는 안되기 때문에 많은 장점을 갖지만, 도커 컨테이너에 있는 ASF는 걱정할 필요가 없다는 편리함도 있습니다. 좋은 사례와 정확한 도커 사용례를 잘 살핀다면 우리가 추천하는 것은 latest 태그가 아닌 released 태그입니다. 하지만 그게 귀찮고 ASF가 동작도 잘하고 자동 업데이트도 하길 원하면 latest 태그가 그 답입니다.

보통 ASF 도커 컨테이너는 Headless: true 일반 설정상태로 실행해야 합니다. 이는 ASF에게 세부적인 내용이 빠져있어도 당신이 줄 수 없으며 묻지 말 것을 알립니다. 물론 초기 설치단계에서는 이 옵션을 false로 해서 쉽게 설정할 수 있지만, 장기적으로는 ASF 콘솔에 매여있지 않으므로 ASF에게 이를 알리고 필요가 있으면 input 명령어 를 사용하는 것이 맞습니다. 이렇게 해서 ASF는 일어나지 않을 사용자 입력을 무한히 기다리지 않을 수 있고 이에 소요되는 자원낭비를 막을 수 있습니다. 또한 이는 ASF가 컨테이너 내부에서 비대화형(non-interactive) 모드로 실행되도록 해주며, 이는 예를 들어 시그널 전달과 관련해 매우 중요합니다. 이를 통해 ASF는 docker stop asf 요청 시 정상적으로 종료될 수 있습니다.