slim

KO | EN

gitlite — search

#hacktoberfest #ai #golang #android #machine-learning #rust #java #windows #cli #vue #awesome-list #ios #mcp #open-source

(★ 23,397)

Slim(toolkit): 컨테이너 이미지의 그 어떤 내용도 변경하지 않고 최대 30배까지(컴파일된 언어의 경우 그 이상) 용량을 줄여주며 보안까지 강화해 줍니다! (무료 및 오픈 소스)

slim 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

![SK](https://raw.githubusercontent.com/slimtoolkit/slim/master/assets/images/dslim/logo.png)
[![Gitter chat](https://img.shields.io/badge/chat-on%20gitter-brightgreen.svg?style=for-the-badge)](https://gitter.im/docker-slim/community)
[![Discord chat](https://img.shields.io/static/v1.svg?label=chat&message=on%20discord&color=7389D8&style=for-the-badge)](https://discord.gg/9tDyxYS)
[![Follow](https://img.shields.io/badge/follow-on%20twitter-%231DA1F2.svg?style=for-the-badge&logoColor=white)](https://twitter.com/DockerSlim)
[![Youtube](https://img.shields.io/badge/-YouTube-red?style=for-the-badge&logo=youtube&logoColor=white)](https://www.youtube.com/channel/UCy7RHjJlaBhpCCbChrd8POA?sub\_confirmation=1)
[![Gitpod ready-to-code](https://img.shields.io/badge/Gitpod-ready--to--code-908a85?logo=gitpod&style=for-the-badge)](https://gitpod.io/#https://github.com/slimtoolkit/slim)
[![Install SlimToolkit](https://img.shields.io/badge/install-slim-blue?style=for-the-badge)](https://github.com/slimtoolkit/slim#installation)
[![Get Examples](https://img.shields.io/badge/slim-app%20examples-green?style=for-the-badge)](https://github.com/slimtoolkit/examples)
[![Try Slim.AI SaaS](https://img.shields.io/badge/try-Slim.AI%20SaaS-red?style=for-the-badge)](https://portal.slim.dev/login?invitecode=invite.1s85zlfnYX0p5TT1XKja49pAHbL)
# 컨테이너 경험 최적화하기. 더 훌륭하고, 더 작고, 더 안전한 컨테이너를 만들고, 최소한의 노력으로 목표를 달성하세요 (무료 및 오픈소스!)
클라우드 네이티브 생태계에서 추가적인 컨테이너 도구 및 런타임에 대한 지원이 확대됨에 따라, 이제 \*\*DockerSlim\*\*은 단순히 \*\*Slim\*\*으로 불립니다(\*\*SlimToolkit\*\*은 정식 명칭이므로 온라인에서 더 쉽게 찾을 수 있습니다).
\*\*Slim\*\*은 이제 CNCF Sandbox 프로젝트입니다. 이 프로젝트는 [Kyle](https://github.com/kcq) [Quest](https://twitter.com/kcqon)가 만들었으며 많은 [기여자들](https://github.com/slimtoolkit/slim/graphs/contributors)에 의해 발전해 왔습니다. 이 프로젝트는 Root.io(구 Slim.AI)의 지원을 받고 있습니다.
Slim과 Root가 협력하는 방식은 다음과 같습니다. Slim은 최적화된 컨테이너를 구축하는 데 도움을 주며, Root.io는 워크플로우를 방해하지 않고 취약점을 자동으로 수정합니다. Slim의 오픈소스 툴키트를 사용하여 컨테이너를 최적화한 다음, Root의 자동화된 취약점 조치 기능을 통해 보안을 유지하세요. 최적화부터 지속적인 보안까지 하나의 매끄러운 여정으로 이어집니다. www.root.io에서 자세히 알아보세요.
## 개요
SlimToolkit은 개발자가 `xray`, `lint`, `build`, `debug`, `run`, `images`, `merge`, `registry`, `vulnerability` 등의 명령어를 사용하여 컨테이너를 검사, 최적화 및 디버깅할 수 있도록 지원합니다. 이 도구는 컨테이너를 빌드, 커스터마이징 및 사용하는 개발자 경험을 단순화하고 향상시킵니다. 원본 및 경량화된 컨테이너를 다룰 때 고급 가시성과 향상된 사용성을 제공하는 동시에, 컨테이너를 더욱 우수하고 작고 안전하게 만들어 줍니다.
컨테이너 이미지의 다른 부분을 전혀 변경하지 않고도 최대 30배까지 크기를 줄이면서 보안까지 강화할 수 있습니다! 하지만 이미지 최적화가 이 도구의 전부는 아닙니다. 더 나은 컨테이너 이미지를 이해하고 작성하는 데도 도움을 줍니다.
기존에 하던 방식을 그대로 유지하세요. 아무것도 바꿀 필요가 없습니다. 원하는 베이스 이미지를 사용하세요. 원하는 패키지 매니저를 사용하세요. Dockerfile을 수동으로 최적화하느라 고민하지 마세요. 작은 컨테이너 이미지를 얻기 위해 기존에 쓰던 도구와 워크플로우를 포기할 필요는 없습니다.
Seccomp 및 AppArmor 보안 프로파일을 수동으로 생성하느라 걱정하지 마세요. 안전한 컨테이너를 만들기 위해 Linux 시스템 콜, Seccomp 및 AppArmor의 전문가가 될 필요는 없습니다. 관련 지식이 충분하다 하더라도 애플리케이션 동작을 리버스 엔지니어링하느라 시간을 낭비하는 것은 비효율적입니다.
SlimToolkit은 다양한 분석 기법을 사용하여 애플리케이션과 그 요구 사항을 파악함으로써 컨테이너를 최적화하고 보호합니다. 불필요한 부분을 제거하여 컨테이너의 공격 표면을 줄여줍니다. 컨테이너를 디버깅하기 위해 그러한 추가적인 요소 중 일부가 필요하다면 어떻게 해야 할까요? 그럴 때는 전용 디버깅 사이드카 컨테이너를 사용할 수 있습니다(자세한 내용은 아래 참조).
SlimToolkit은 Ubuntu, Debian, CentOS, Alpine 심지어 Distroless에서 실행되는 Node.js, Python, Ruby, Java, Go, Rust, Elixir 및 PHP(일부 앱 유형)와 함께 사용되어 왔습니다.
동적으로 로드되는 모든 컴포넌트가 확실하게 감지되도록 일부 애플리케이션 스택은 고급 컨테이너 프로빙이 필요할 수 있습니다. 사용자 정의 프로브 명령어를 정의하는 방법에 대한 자세한 내용은 `--http-probe\*` 플래그를 참조하세요. 경우에 따라 애플리케이션에 필요한 모든 것이 포함되도록 `--include-path` 플래그를 사용해야 할 수도 있습니다(예: 클라이언트 측 템플릿 파일이 명시적으로 포함된 `ubuntu.com` 파이썬 SPA 앱 컨테이너 이미지 [예시](https://github.com/slimtoolkit/examples/tree/master/3rdparty/ubuntu-com) 참조).
또한 Slim 앱을 실행할 때 앱/환경 테스트를 함께 사용하는 것이 좋습니다. 테스트를 동적 분석 수행 시 Slim이 생성하는 임시 컨테이너와 통합하는 방법에 대한 자세한 내용은 `--continue-after` 플래그를 참조하세요. 타겟 컨테이너 내에서 테스트를 실행하는 것도 하나의 방법이지만, 이 경우 앱을 시작하고 테스트를 실행하기 위한 커스텀 래퍼와 함께 커스텀 ENTRYPOINT/CMD를 지정해야 합니다.
![Slim How](https://raw.githubusercontent.com/slimtoolkit/slim/master/assets/images/docs/SlimHow.jpeg)
인터랙티브 CLI 프롬프트 스크린캐스트:
[![asciicast](https://raw.githubusercontent.com/slimtoolkit/slim/master/assets/images/dslim/DockerSlimIntPromptDemo.gif)](https://asciinema.org/a/311513)
애플리케이션 이미지가 30배 이상 경량화되는 과정을 이 스크린캐스트에서 확인해 보세요.
[![asciicast](https://asciinema.org/a/rHqW8cbr3vXe0WxorHsD36n7V.png)](https://asciinema.org/a/rHqW8cbr3vXe0WxorHsD36n7V)
Slim에서 `build` 또는 `profile` 명령어를 실행하면 생성된 임시 컨테이너와 상호작용할 수 있는 기회가 주어집니다. 기본적으로 실행을 계속하기 전에 일시 중지하고 입력을 기다립니다. `--continue-after` 플래그를 사용하여 이 동작을 변경할 수 있습니다.
애플리케이션이 웹 인터페이스를 노출하는 경우(예: 웹 서버나 HTTP API가 있는 경우), 애플리케이션과 상호작용하는 데 필요한 호스트 머신의 포트 번호가 표시됩니다(화면의 `port.list` 및 `target.port.info` 메시지 확인). 예를 들어, 위의 스크린캐스트에서는 내부 애플리케이션 포트 8000이 호스트의 포트 32911에 매핑된 것을 볼 수 있습니다.
HTTP 프로빙이 활성화되어 있으면(기본적으로 활성화됨; 자세한 내용은 `--http-probe\*` 플래그 문서 참조) Slim이 사용자를 대신하여 애플리케이션과 상호작용합니다. Python이나 Ruby 같은 스크リп트 언어로 빌드된 일부 웹 애플리케이션은 애플리케이션의 모든 것을 로드하기 위해 서비스 상호작용이 필요합니다. 업무에 방해가 되지 않는 한 HTTP 프로빙을 활성화해 두세요.
`--exec-file` 또는 `--exec`을 사용하여 셸 스크립트나 스니펫을 통해 임시 컨테이너와 상호작용할 수도 있습니다. 예를 들어, curl을 사용하는 기능만 가진 컨테이너를 만들 수 있습니다.
```bash
>> docker pull archlinux:latest
...
>> slim build --target archlinux:latest --tag archlinux:curl --http-probe=false --exec "curl checkip.amazonaws.com"
...
>> docker run archlinux:curl curl checkip.amazonaws.com
...
>> docker images
archlinux curl ... ... 17.4MB
archlinux latest ... ... 467MB
...
```
## 커뮤니티
의견을 나누고 싶거나 도움이 필요하다면 언제든지 아래 채널에 참여하시거나 [`Github issue`](https://github.com/slimtoolkit/slim/issues)를 새로 열어주세요.
\* [`CNCF Slack channel`](https://cloud-native.slack.com/archives/C059QP1RH1S)
\* [`Discord server`](https://discord.gg/9tDyxYS)
\* [`Discussions`](https://github.com/slimtoolkit/slim/discussions)
\* [`Twitter`](https://twitter.com/SlimToolkit)
## 인터넷상의 SlimToolkit
##### 도서:
\* [`모두를 위한 Docker/Kubernetes`](https://www.amazon.co.jp/dp/429710461X) (일본어)
\* [`Docker in Practice (2nd edition)`](https://www.amazon.com/Docker-Practice-Ian-Miell/dp/1617294802)
\* [`Docker/Kubernetes 보안 실전 가이드`](https://www.amazon.co.jp/dp/4839970505) (일본어)
## 경량화 예시
별도의 리포지토리에서 예시를 확인할 수 있습니다: [https://github.com/slimtoolkit/examples](https://github.com/slimtoolkit/examples)
Node.js 애플리케이션 이미지:
- ubuntu:14.04 기반 - 432MB => 14MB (\*\*30.85배\*\* 경량화)
- debian:jessie 기반 - 406MB => 25.1MB (\*\*16.21배\*\* 경량화)
- node:alpine 기반 - 66.7MB => 34.7MB (\*\*1.92배\*\* 경량화)
- node:distroless 기반 - 72.7MB => 39.7MB (\*\*1.83배\*\* 경량화)
Python 애플리케이션 이미지:
- ubuntu:14.04 기반 - 438MB => 16.8MB (\*\*25.99배\*\* 경량화)
- python:2.7-alpine 기반 - 84.3MB => 23.1MB (\*\*3.65배\*\* 경량화)
- python:2.7.15 기반 - 916MB => 27.5MB (\*\*33.29배\*\* 경량화)
- centos:7 기반 - 647MB => 23MB (\*\*28.57배\*\* 경량화)
- centos/python-27-centos7 기반 - 700MB => 24MB (\*\*29.01배\*\* 경량화)
- python2.7:distroless 기반 - 60.7MB => 18.3MB (\*\*3.32배\*\* 경량화)
Ruby 애플리케이션 이미지:
- ubuntu:14.04 기반 - 433MB => 13.8MB (\*\*31.31배\*\* 경량화)
- ruby:2.2-alpine 기반 - 319MB => 27MB (\*\*11.88배\*\* 경량화)
- ruby:2.5.3 기반 - 978MB => 30MB (\*\*32.74배\*\* 경량화)
Go 애플리케이션 이미지:
- golang:latest 기반 - 700MB => 1.56MB (\*\*448.76배\*\* 경량화)
- ubuntu:14.04 기반 - 531MB => 1.87MB (\*\*284.10배\*\* 경량화)
- golang:alpine 기반 - 258MB => 1.56MB (\*\*165.61배\*\* 경량화)
- centos:7 기반 - 615MB => 1.87MB (\*\*329.14배\*\* 경량화)
Rust 애플리케이션 이미지:
- rust:1.31 기반 - 2GB => 14MB (\*\*147.16배\*\* 경량화)
Java 애플리케이션 이미지:
- ubuntu:14.04 기반 - 743.6 MB => 100.3 MB
PHP 애플리케이션 이미지:
- php:7.0-cli 기반 - 368MB => 26.6MB (\*\*13.85배\*\* 경량화)
Haskell 애플리케이션 이미지:
- (Scotty 서비스) haskell:8 기반 - 2.09GB => 16.6MB (\*\*125.32배\*\* 경량화)
- (Scotty 서비스) haskell:7 기반 - 1.5GB => 21MB (71배 경량화)
Elixir 애플리케이션 이미지:
- (Phoenix 서비스) elixir:1.6 기반 - 1.1 GB => 37 MB (\*\*29.25배\*\* 경량화)
---

- [최근 업데이트](#recent-updates)
- [설치](#installation)
- [기본 사용법 정보](#basic-usage-info)
- [명령어](#commands)
- [사용법 상세](#usage-details)
- [`LINT` 명령어 옵션](#lint-command-options)
- [`XRAY` 명령어 옵션](#xray-command-options)
- [`BUILD` 명령어 옵션](#build-command-options)
- [`DEBUG` 명령어 옵션](#debug-command-options)
- [`RUN` 명령어 옵션](#run-command-options)
- [`REGISTRY` 명령어 옵션](#registry-command-options)
- [`VULNERABILITY` 명령어 옵션](#vulnerability-command-options)
- [컨테이너 환경에서 실행하기](#running-containerized)
- [DOCKER 연결 옵션](#docker-connect-options)
- [HTTP 프로브 명령어](#http-probe-commands)
- [최소화된 컨테이너 디버깅하기](#debugging-minified-containers)
- [명령줄 도구 최소화하기](#minifying-command-line-tools)
- [간단한 SECCOMP 예제](#quick-seccomp-example)
- [자동 생성된 SECCOMP 프로필 사용하기](#using-auto-generated-seccomp-profiles)
- [원본 데모 영상](#original-demo-video)
- [데모 단계](#demo-steps)
- [FAQ](#faq)
- [프로덕션 환경에서 사용해도 안전한가요?](#is-it-safe-for-production-use)
- [Go 언어를 모르는데 어떻게 기여할 수 있나요?](#how-can-i-contribute-if-i-dont-know-go)
- [Slim에 가장 적합한 애플리케이션은 무엇인가요?](#whats-the-best-application-for-slim)
- [Docker화된 명령줄 도구와 함께 Slim을 사용할 수 있나요?](#can-i-use-slim-with-dockerized-command-line-tools)
- [Docker 이미지에서 USER 명령을 사용하는 경우는 어떻게 하나요?](#what-if-my-docker-images-uses-the-user-command)
- [최소화된 이미지에서 Nginx가 실패합니다](#nginx-fails-in-my-minified-image)
- [Slim이 '읽기 권한 없음' 오류와 함께 실패합니다](#slim-fails-with-a-no-permission-to-read-from-error)
- [빌드 프로세스](#build-process)
- [빌드 단계](#build-steps)
- [기여하기](#contributing)
- [설계](#design)
- [핵심 개념](#core-concepts)
- [동적 분석 옵션](#dynamic-analysis-options)
- [보안](#security)
- [과제](#challenges)
- [기원](#origins)
- [DOCKER HUB의 최소화된 이미지](#minified-images-on-docker-hub)
- [라이선스](#license)
## 최근 업데이트
최신 버전: `1.40.11` (`2024년 2월 2일`)
1.40.11 버전은 최신 Docker Engine 버전에 대한 지원을 추가하고, `xray` 리포트를 개선하며, 새로운 `build` 명령어 플래그(`--include-dir-bins` 및 `--include-ssh-client`)를 추가합니다.
최신 릴리스에 대한 자세한 내용은 [`CHANGELOG`](CHANGELOG.md)를 참조하세요.
## 설치
이미 Slim이 설치되어 있는 경우 `update` 명령어를 사용하여 최신 버전을 받을 수 있습니다:
```
slim update
```
### 다운로드
1. 사용 중인 플랫폼에 맞는 zip 패키지를 다운로드하세요.
- [최신 Mac 바이너리](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_mac.zip) (`curl -L -o ds.zip https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_mac.zip`)
- [최신 Mac M1 바이너리](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_mac\_m1.zip) (`curl -L -o ds.zip https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_mac\_m1.zip)`)
- [최신 Linux 바이너리](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux.tar.gz) (`curl -L -o ds.tar.gz https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux.tar.gz`)
- [최신 Linux ARM 바이너리](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux\_arm.tar.gz) (`curl -L -o ds.tar.gz https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux\_arm.tar.gz`)
- [최신 Linux ARM64 바이너리](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux\_arm64.tar.gz) (`curl -L -o ds.tar.gz https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux\_arm64.tar.gz`)
2. 패키지의 압축을 풀고 선택적으로 bin 디렉토리로 이동하세요.
Linux (인텔이 아닌 경우 `dist\_linux`를 플랫폼별 압축 해제 경로로 교체하세요):
```
tar -xvf ds.tar.gz
mv dist\_linux/slim /usr/local/bin/
mv dist\_linux/slim-sensor /usr/local/bin/
```
Mac:
```
unzip ds.zip
mv dist\_mac/slim /usr/local/bin/
mv dist\_mac/slim-sensor /usr/local/bin/
```
3. 패키지 압축을 푼 디렉토리를 PATH 환경 변수에 추가하세요(선택 사항).
바이너리를 추출한 디렉토리가 PATH에 없으면 해당 디렉토리에서 Slim 앱 바이너리를 실행해야 합니다.
#### 스크립트 설치
이 스크립트를 사용하여 Linux(x86 및 ARM)와 macOS(x86 및 Apple Silicon)에 Slim의 현재 릴리스를 설치할 수도 있습니다.
```bash
curl -sL https://raw.githubusercontent.com/slimtoolkit/slim/master/scripts/install-slim.sh | sudo -E bash -
```
### Homebrew
```
brew install docker-slim
```
Homebrew 설치 관리자: https://formulae.brew.sh/formula/docker-slim
### Docker
```
docker pull dslim/slim
```
사용법에 대한 자세한 내용은 [컨테이너 환경에서 실행하기](#running-containerized) 섹션을 참조하세요.
### SaaS
Slim 기반 서비스입니다. 애플리케이션 컨테이너를 이해하고 트러블슈팅하는 데 도움을 줍니다. `xray` 명령어를 사용한다면 SaaS도 꼭 시도해 보세요. 컨테이너 diff 기능을 통해 이미지 변경 사항을 쉽게 파악할 수 있습니다. 자신의 레지스트리를 연결하면 자체 컨테이너에서도 동일하게 수행할 수 있습니다. 로컬에 아무것도 설치하지 않고 [여기](https://portal.slim.dev/login?invitecode=invite.1s85zlfnYX0p5TT1XKja49pAHbL)에서 체험해 보세요.
## 기본 사용법 정보
`slim [global flags] [xray|build|profile|run|debug|lint|merge|images|registry|vulnerability|update|version|appbom|help] [command-specific flags] `
아무 명령어도 지정하지 않으면 `slim`은 대화형 프롬프트 모드로 시작됩니다.
### 명령어
- `xray` - 대상 컨테이너 이미지에 대한 정적 분석을 수행합니다(이미지의 Dockerfile '역공학' 포함). 컨테이너 이미지 내부의 내용과 무엇이 용량을 차지하는지 알고 싶을 때 이 명령어를 사용하세요.
- `lint` - Dockerfile의 컨테이너 지침을 분석합니다(Docker 이미지 지원은 작업 중).
- `build` - 컨테이너 이미지를 분석, 프로파일링 및 최적화하여 지원되는 보안 프로필을 생성합니다. 가장 인기 있는 명령어입니다.
- `debug` - 실행 중인 대상 컨테이너를 디버깅합니다. 이 명령어는 최소화/경량화되었거나 일반적인 컨테이너 이미지로 생성된 실행 중인 컨테이너를 트러블슈팅하는 데 유용합니다.
- `registry` - 레지스트리 작업을 실행합니다 (`pull`, `push`, `copy`, `server`).
- `profile` - 기본적인 컨테이너 이미지 분석 및 동적 컨테이너 분석을 수행하지만, 최적화된 이미지를 생성하지는 않습니다.
- `run` - 하나 이상의 컨테이너를 실행합니다(현재는 `docker run`과 유사하게 단일 컨테이너를 실행함).
- `merge` - 두 개의 컨테이너 이미지를 병합합니다(경량화된 이미지 병합에 최적화됨).
- `images` - 컨테이너 이미지에 대한 정보를 가져옵니다 (예: `slim --quiet images`).
- `vulnerability` - 취약성 관련 도구 및 작업을 실행합니다 (`epss`).
- `version` - 버전 정보를 표시합니다.
- `appbom` - 애플리케이션 BOM(앱 구성/종속성)을 표시합니다.
- `update` - Slim을 최신 버전으로 업데이트합니다.
- `help` - 사용 가능한 명령어와 전역 플래그를 표시합니다.
예시: `slim build my/sample-app`
자세한 내용은 `사용법 상세` 섹션을 참조하세요. 사용 가능한 명령어에 대한 개요를 보려면 `slim help`를 실행하세요. 매개변수 없이 `slim COMMAND\_NAME`을 실행하면 해당 명령어에 대한 자세한 정보를 볼 수 있습니다 (예: `slim build`).
매개변수 없이 `slim`을 실행하면 사용 가능한 명령어와 플래그에 대한 제안을 제공하는 대화형 프롬프트가 나타납니다. `Tab` 키를 사용하여 사용 가능한 옵션을 표시하고, 매개변수를 자동 완성하며, 옵션 메뉴를 탐색할 수 있습니다(위/아래 화살표로도 가능합니다). `Space` 키는 다음 매개변수로 이동하는 데 사용되며, `Enter` 키는 명령어를 실행하는 데 사용됩니다. 대화형 프롬프트에 대한 자세한 내용은 [`go-prompt`](https://github.com/c-bata/go-prompt)를 참조하세요.
## 사용법 상세
`slim [global options] command [command options] `
명령어:
- `xray` - 컨테이너 이미지의 내용을 표시하고 Dockerfile을 역공학합니다.
- `lint` - 대상 Dockerfile을 린트합니다(향후 이미지도 지원 예정).
- `build` - 대상 컨테이너 이미지와 그 애플리케이션을 분석하고 그로부터 최적화된 이미지를 빌드합니다.
- `debug` - 실행 중인 대상 컨테이너를 디버깅합니다. 이 명령어는 최소화/경량화되었거나 일반적인 컨테이너 이미지로 생성된 실행 중인 컨테이너를 트러블슈팅하는 데 유용합니다.
- `registry` - 레지스트리 작업을 실행합니다 (`pull`, `push`, `copy`, `server`).
- `profile` - 비대한 이미지 정보를 수집하고 비대한 컨테이너 리포트를 생성합니다.
- `merge` - 두 개의 컨테이너 이미지를 병합합니다(경량화된 이미지 병합에 최적화됨).
- `images` - 컨테이너 이미지에 대한 정보를 가져옵니다.
- `vulnerability` - 취약성 관련 도구 및 작업을 실행합니다 (`epss`).
- `appbom` - 애플리케이션 BOM(앱 구성/종속성)을 표시합니다.
- `version` - 앱 및 Docker 버전 정보를 표시합니다.
- `update` - 앱을 업데이트합니다.
- `help` - 도움말 정보를 표시합니다.
전역 옵션:
- `--report` - 명령어 리포트 위치 (실행된 명령어 결과를 저장할 대상 위치; 기본값은 `slim.report.json`; 비활성화하려면 `off`로 설정)
- `--check-version` - 현재 버전이 구버전인지 확인
- `--version` - 버전 출력
- `--debug` - 디버그 로그 활성화
- `--verbose` - 정보 로그 활성화
- `--log-level` - 로깅 수준 설정 ('debug', 'info', 'warn'(기본값), 'error', 'fatal', 'panic')
- `--log-format` - 로그가 사용하는 형식 설정 ('text'(기본값) 또는 'json')
- `--crt-api-version` - 컨테이너 런타임 API 버전
- `--quiet` - 간결한 CLI 실행 모드
- `--output-format` - 사용할 출력 형식 설정 ('text'(기본값) 또는 'json')
- `--log` - 로그를 저장할 로그 파일
- `--host` - Docker 호스트 주소 또는 소켓 (`tcp://` 또는 `unix://` 접두사 사용)
- `--tls` - Docker에 연결할 때 TLS 사용
- `--tls-verify` - TLS 검증 수행
- `--tls-cert-path` - TLS 인증서 파일 경로
- `--state-path value` - Slim 상태 기본 경로 (Slim 바이너리가 쓰기 가능한 디렉토리에 없는 경우 반드시 설정해야 함!)
- `--archive-state` - Slim 상태를 선택한 Docker 볼륨에 아카이브합니다 (기본 볼륨 - `slim-state`). 기본적으로 Slim이 컨테이너에서 실행 중일 때 활성화됩니다(그 외에는 비활성화). 명시적으로 비활성화하려면 `off`로 설정하세요.
- `--in-container` - Slim이 컨테이너에서 실행 중임을 명시적으로 나타내려면 true로 설정하세요 (설정하지 않으면 Slim은 실행 중인 환경을 분석하여 컨테이너화되었는지 확인하려고 시도합니다).
버전 검사를 비활성화하려면 전역 `--check-version` 플래그를 `false`로 설정하거나(예: `--check-version=false`) `DSLIM\_CHECK\_VERSION` 환경 변수를 사용할 수 있습니다.
### `LINT` 명령어 옵션
- `--target` - 대상 Dockerfile 경로 (향후 Docker 이미지도 지원; 이 플래그를 사용하지 않는 경우 명령의 인수로 대상을 지정해야 합니다)
- `--target-type` - 명령어 대상 유형을 명시적으로 지정 (값: dockerfile, image)
- `--skip-build-context` - 빌드 컨텍스트 분석을 시도하지 않음
- `--build-context-dir` - 빌드 컨텍스트 디렉토리를 명시적으로 지정
- `--skip-dockerignore` - .dockerignore 분석을 시도하지 않음
- `--include-check-label` - 선택한 라벨 key:value가 있는 검사 포함
- `--exclude-check-label` - 선택한 라벨 key:value가 있는 검사 제외
- `--include-check-id` - 포함할 검사 ID
- `--include-check-id-file` - 포함할 검사 ID가 있는 파일
- `--exclude-check-id` - 제외할 검사 ID
- `--exclude-check-id-file` - 제외할 검사 ID가 있는 파일
- `--show-nohits` - 일치 항목이 없는 검사 표시
- `--show-snippet` - 검사 일치 스니펫 표시 (기본값: true)
- `--list-checks` - 사용 가능한 검사 목록 표시 (사용 가능한 검사 목록만 확인하려는 경우 대상 플래그를 지정할 필요 없음)
### `XRAY` 명령어 옵션
- `--target` - 대상 컨테이너 이미지 (이름 또는 ID)
- `--pull` - 로컬에 없는 경우 대상 풀 시도 (기본값: false).
- `--docker-config-path` - 레지스트리 자격 증명을 가져오는 데 사용되는 Docker 설정 경로 설정 (`--pull` 플래그와 함께 사용).
- `--registry-account` - 비공개 레지스트리에서 이미지를 풀할 때 사용할 계정 (`--pull` 플래그와 함께 사용).
- `--registry-secret` - 비공개 레지스트리에서 이미지를 풀할 때 사용할 계정 비밀번호 (`--pull` 및 `--registry-account` 플래그와 함께 사용).
- `--show-plogs` - 이미지 풀 로그 표시 (기본값: false).
- `--changes value` - 선택한 변경 유형에 대한 레이어 변경 세부 정보 표시 (값: none, all, delete, modify, add).
- `--changes-output value` - 변경 사항을 표시할 위치 (값: all, report, console).
- `--layer value` - 선택한 레이어에 대한 세부 정보 표시 (레이어 인덱스 또는 ID 사용)
- `--add-image-manifest` - 명령어 실행 리포트 파일에 원시 이미지 매니페스트 추가
- `--add-image-config` - 명령어 실행 리포트 파일에 원시 이미지 설정 객체 추가
- `--layer-changes-max` - 각 레이어에 대해 표시할 최대 변경 횟수
- `--all-changes-max` - 모든 레이어에 대해 표시할 최대 변경 횟수
- `--add-changes-max` - 모든 레이어에 대해 표시할 최대 `add` 변경 횟수
- `--modify-changes-max` - 모든 레이어에 대해 표시할 최대 `modify` 변경 횟수
- `--delete-changes-max` - 모든 레이어에 대해 표시할 최대 `delete` 변경 횟수
- `--change-path value` - 경로 패턴과 일치하는 파일에 대한 변경 사항 포함 (Go 및 \*\*의 Glob/Match). 값 형식: `` | `dump::` | `::` (여기서 `output type`은 `console` 또는 디렉토리 이름). `value`가 `dump:`로 시작하면 일치하는 항목이 선택한 `output type`으로 '덤프'됩니다. [이 플래그를 여러 번 사용할 수 있습니다]
- `--change-data value` - 데이터 패턴(정규식)과 일치하는 파일에 대한 변경 사항 포함. 값 형식: `` | `dump:::` | `:::` | `:::` (여기서 `output type`은 `console` 또는 디렉토리 이름). `value`가 `dump:`로 시작하면 일치하는 항목이 선택한 `output type`으로 '덤프'됩니다. [이 플래그를 여러 번 사용할 수 있습니다]
- `--change-data-hash value` - 제공된 데이터 해시(sha1)와 일치하는 파일에 대한 변경 사항 포함. 값 형식: `` | `dump::` | `::` (여기서 `output type`은 `console` 또는 디렉토리 이름). `value`가 `dump:`로 시작하면 일치하는 항목이 선택한 `output type`으로 '덤프'됩니다. [이 플래그를 여러 번 사용할 수 있습니다]
- `--reuse-saved-image` - 저장된 컨테이너 이미지 재사용 (기본값: true).
- `--top-changes-max` - 추적할 상위 변경 사항의 최대 수 (기본값: 20).
- `--hash-data` - 파일 데이터 해시 생성 (기본값: false).
- `--detect-duplicates` - 해시를 기반으로 중복 파일 감지 (기본값: true).
- `--show-duplicates` - 발견된 모든 중복 파일 경로 표시 (기본값: false).
- `--show-special-perms` - 특수 권한이 있는 파일 표시 (setuid, setgid, sticky) (기본값: true)
- `--detect-utf8` - utf8 파일 감지 및 선택적으로 발견된 utf8 파일 내용 추출 (가능한 값: "true" 또는 "dump" 또는 "dump:output\_target.tgz" 또는 "dump:output\_target.tgz::max\_size\_bytes" 또는 "dump:output\_target.tgz:::max\_size\_bytes").
- `--detect-all-certs` - 모든 인증서 파일 감지
- `--detect-all-cert-pks` - 모든 인증서 개인 키 파일 감지
- `--detect-identities` - 시스템 ID(사용자, 그룹) 및 그 속성 감지 (기본값: true)
- `--change-match-layers-only` - 변경 일치 항목이 있는 레이어만 표시 (기본값: false).
- `--export-all-data-artifacts` - 모든 텍스트 데이터 아티팩트를 내보낼 TAR 아카이브 파일 경로 (`.`으로 설정하면 아카이브 파일 경로의 기본값은 `./data-artifacts.tar`가 됩니다)
- `--remove-file-artifacts` - 명령어가 완료되면 파일 아티팩트 제거 (참고: 역공학된 Dockerfile을 잃게 됩니다)
변경 유형:
- `none` - 이미지 레이어의 파일 시스템 변경 세부 정보를 표시하지 않음(해당 레이어의 상위 변경 사항은 계속 표시됨)
- `all` - 이미지 레이어의 모든 파일 시스템 변경 세부 정보 표시
- `delete` - 이미지 레이어의 `delete` 파일 시스템 변경 세부 정보만 표시
- `modify` - 이미지 레이어의 `modify` 파일 시스템 변경 세부 정보만 표시
- `add` - 이미지 레이어의 'add' 파일 시스템 변경 세부 정보만 표시
대화형 CLI 프롬프트 모드에서는 `--target` 플래그를 사용하여 대상 이미지를 지정해야 하며, 전통적인 CLI 모드에서는 `--target` 플래그를 사용하거나 명령어의 마지막 값으로 대상 이미지를 지정할 수 있습니다.
### `BUILD` 명령어 옵션
- `--target` - 대상 컨테이너 이미지 (이름 또는 ID). 대상 정보를 제공하는 대체 방법입니다. 대상 정보를 제공하는 표준 방법은 `build` 명령어 CLI 호출의 마지막 값으로 넣는 것입니다.
- `--pull` - 로컬에 없는 경우 대상 풀 시도 (기본값: false).
- `--docker-config-path` - 레지스트리 자격 증명을 가져오는 데 사용되는 Docker 설정 경로 설정 (`--pull` 플래그와 함께 사용).
- `--registry-account` - 비공개 레지스트리에서 이미지를 풀할 때 사용할 계정 (`--pull` 플래그와 함께 사용).
- `--registry-secret` - 비공개 레지스트리에서 이미지를 풀할 때 사용할 계정 비밀번호 (`--pull` 및 `--registry-account` 플래그와 함께 사용).
- `--show-plogs` - 이미지 풀 로그 표시 (기본값: false).
- `--compose-file` - 선택한 compose 파일에서 컨테이너 정보 로드
- `--target-compose-svc` - compose 파일의 대상 서비스
- `--target-compose-svc-image` - target-compose-svc 매개변수를 사용하여 compose를 타겟팅할 때 컨테이너 이미지 이름 및/또는 태그 오버라이드 (형식: tag\_name 또는 image\_name:tag\_name)
- `--target-compose-svc-no-ports` - compose 파일의 대상 서비스에 대한 포트를 게시하지 않음
- `--dep-exclude-compose-svc-all` - 대상 종속성으로 어떤 compose 서비스도 시작하지 않음
- `--dep-include-compose-svc` - 특정 compose 서비스를 대상 종속성으로 포함 (선택한 서비스만 시작됨)
- `--dep-exclude-compose-svc` - 대상 종속성으로 시작될 compose 서비스에서 특정 서비스 제외
- `--dep-include-compose-svc-deps` - 선택한 compose 서비스의 모든 종속성(서비스 자체 제외)을 대상 종속성으로 포함
- `--dep-include-target-compose-svc-deps` - 대상 compose 서비스의 모든 종속성(서비스 자체 제외)을 대상 종속성으로 포함. 서비스 이름을 반복하지 않기 위한 단축 플래그입니다 (이름이 꽤 깁니다 :-))
- `--compose-svc-start-wait` - 각 compose 서비스를 시작하기 전에 대기할 시간(초)
- `--compose-net` - 대상을 선택한 compose 네트워크에 연결, 그렇지 않으면 모든 네트워크가 연결됨
- `--compose-env-nohost` - 호스트의 환경 변수를 compose에 포함하지 않음
- `--compose-env-file` - 파일에서 compose 환경 변수 로드 (호스트 환경 변수가 이 파일에서 로드된 값을 오버라이드함)
- `--compose-workdir` - compose를 위한 사용자 지정 작업 디렉토리 설정
- `--compose-project-name` - compose를 위한 사용자 지정 프로젝트 이름 사용
- `--container-probe-compose-svc` - compose 파일의 컨테이너 테스트/프로브 서비스
- `--prestart-compose-svc` - 현재는 자리표시자
- `--poststart-compose-svc` - 현재는 자리표시자
- `--http-probe` - HTTP 프로빙 활성화/비활성화 (기본적으로 활성화됨; 필요하지 않은 경우 플래그를 `false`로 설정하여 비활성화해야 함: `--http-probe=false`)
- `--http-probe-off` - HTTP 프로빙을 비활성화하는 대체 방법
- `--http-probe-cmd` - 추가 HTTP 프로브 명령어 [이 플래그를 여러 번 사용할 수 있습니다]
- `--http-probe-cmd-file` - 사용자가 정의한 HTTP 프로브 명령어가 있는 파일
- `--http-probe-start-wait` - HTTP 프로빙을 시작하기 전에 대기할 시간(초)
- `--http-probe-retry-count` - 각 HTTP 프로브의 재시도 횟수 (기본값: 5)
- `--http-probe-retry-wait` - HTTP 프로브 재시도 전 대기할 시간(초) (대상이 준비되지 않은 경우 두 배로 증가; 기본값: 8)
- `--http-probe-ports` - 프로브할 포트의 명시적 목록 (프로브하려는 순서대로; 제외된 포트는 프로브되지 않음!)
- `--http-probe-full` - 선택한 모든 포트에 대해 전체 HTTP 프로브 수행 (false인 경우 첫 번째 성공적인 스캔 후 종료; 기본값: false)
- `--http-probe-exit-on-failure` - 모든 HTTP 프로브 명령어가 실패할 때 종료 (기본값: true)
- `--http-probe-crawl` - 기본 HTTP 프로브 명령어에 대한 크롤링 활성화 (기본값: true)
- `--http-crawl-max-depth` - HTTP 프로브 크롤러에 사용할 최대 깊이 (기본값: 3)
- `--http-crawl-max-page-count` - HTTP 프로브 크롤러가 방문할 최대 페이지 수 (기본값: 1000)
- `--http-crawl-concurrency` - HTTP 타겟을 크롤링할 때 동시 작업자 수 (기본값: 10)
- `--http-max-concurrent-crawlers` - HTTP 프로브의 동시 크롤러 수 (기본값: 1)
- `--http-probe-apispec` - 스펙을 사용할 수 있는 대상 경로를 나타내는 값으로 API 스펙에 대한 HTTP 프로브 실행 (Swagger 2.x 및 OpenAPI 3.x 지원) [이 플래그를 여러 번 사용할 수 있습니다]
- `--http-probe-apispec-file` - 파일에서 API 스펙에 대한 HTTP 프로브 실행 (Swagger 2.x 및 OpenAPI 3.x 지원) [이 플래그를 여러 번 사용할 수 있습니다]
- `--http-probe-exec` - HTTP 프로브를 실행할 때 실행할 앱. [이 플래그를 여러 번 사용할 수 있습니다]
- `--http-probe-exec-file` - 파일에서 로드된 HTTP 프로브를 실행할 때 실행할 앱.
- `--publish-port` - 런타임에 이미지를 분석하여 컨테이너 포트를 호스트 포트에 매핑하여 외부 테스트 통합을 용이하게 함 (형식 => port | hostPort:containerPort | hostIP:hostPort:containerPort | hostIP::containerPort )[이 플래그를 여러 번 사용할 수 있습니다]
- `--publish-exposed-ports` - 런타임에 이미지를 분석하여 노출된 모든 포트를 동일한 호스트 포트에 매핑 (기본값: false)
- `--show-clogs` - 컨테이너 로그 표시 (동적 검사를 수행하는 데 사용된 컨테이너에서)
- `--show-blogs` - 빌드 로그 표시 (경량화된 컨테이너가 빌드될 때)
- `--copy-meta-artifacts` - 메타 아티팩트를 제공된 위치로 복사
- `--remove-file-artifacts` - 명령어가 완료되면 파일 아티팩트 제거 (참고: `copy-meta-artifacts` 플래그로 복사하거나 상태를 아카이브하지 않으면 자동 생성된 Seccomp 및 Apparmor 프로필을 잃게 됩니다)
- `--tag` - 생성된 이미지에 사용자 지정 태그 사용 (기본값 대신: `.slim`) [최적화된 이미지에 대한 추가 태그를 생성해야 하는 경우 이 플래그를 여러 번 사용할 수 있습니다]
- `--entrypoint` - 런타임에 이미지를 분석하여 ENTRYPOINT 오버라이드
- `--cmd` - 런타임에 이미지를 분석하여 CMD 오버라이드
- `--mount` - 이미지를 분석하는 동안 볼륨 마운트 (마운트 매개변수 형식은 Docker의 `-v` 마운트 명령어와 동일함) [이 플래그를 여러 번 사용할 수 있습니다]
- `--include-path` - 이미지에서 디렉토리(및 그 안의 내용) 또는 파일 포함 [이 플래그를 여러 번 사용할 수 있습니다] (선택적으로 아티팩트의 권한, 사용자 및 그룹 정보 오버라이드; 전체 형식: `targetPath:octalPermFlags#uid#gid`, 최소 형식: `targetPath` ; 자세한 내용은 기본값이 아닌 USER FAQ 섹션 참조)
- `--include-path-file` - 파일에서 디렉토리 또는 파일 포함 항목 로드 (선택적으로 아티팩트의 권한, 사용자 및 그룹 정보 오버라이드; 전체 형식: `targetPath:octalPermFlags#uid#gid`, 최소 형식: `targetPath` ; 자세한 내용은 기본값이 아닌 USER FAQ 섹션 참조)
- `--include-paths-creport-file` - 참조된 creport의 파일 유지
- `--include-bin value` - 이미지에서 바이너리 포함 (절대 경로를 사용하는 실행 파일 또는 공유 객체)
- `--include-bin-file` - 파일에서 공유 바이너리 파일 포함 항목 로드 (`--include-path-file`과 유사)
- `--include-dir-bins value` - 대상 디렉토리의 바이너리를 포함하고 다른 위치에 있을 수 있는 그 종속성을 포함 (절대 경로를 사용하는 실행 파일 또는 공유 객체)
- `--include-exe value` - 이미지에서 실행 파일 포함 (실행 파일 이름으로)
- `--include-exe-file` - 파일에서 실행 파일 포함 항목 로드 (`--include-path-file`과 유사)
- `--include-shell` - 기본 쉘 기능 포함 (기본값: false)
- `--include-workdir` - 작업 디렉토리의 파일 유지 (기본값: false)
- `--include-cert-all` - 발견된 모든 인증서 파일 유지 (기본값: true)
- `--include-cert-bundles-only` - 인증서 번들만 유지
- `--include-cert-dirs` - 알려진 인증서 디렉토리와 그 안의 모든 파일 유지
- `--include-cert-pk-all` - 발견된 모든 인증서 개인 키 유지
- `--include-cert-pk-dirs` - 알려진 인증서 개인 키 디렉토리와 그 안의 모든 파일 유지
- `--include-new` - 동적 분석 중에 대상에 의해 생성된 새 파일 유지 (기본값: true)
- `--include-oslibs-net` - 일반 네트워킹 OS 라이브러리 유지 (기본값: true)
- `--include-ssh-client` - 일반 SSH 클라이언트 구성요소 및 설정 유지
- `--include-zoneinfo` - OS/libc zoneinfo 데이터 유지 (기본값: false)
- `--include-app-nuxt-dir` - 루트 Nuxt.js 앱 디렉토리 유지 (기본값: false)
- `--include-app-nuxt-build-dir` - 빌드 Nuxt.js 앱 디렉토리 유지 (기본값: false)
- `--include-app-nuxt-dist-dir` - dist Nuxt.js 앱 디렉토리 유지 (기본값: false)
- `--include-app-nuxt-static-dir` - Nuxt.js 앱용 정적 에셋 디렉토리 유지 (기본값: false)
- `--include-app-nuxt-nodemodules-dir` - Nuxt.js 앱용 node modules 디렉토리 유지 (기본값: false)
- `--include-app-next-dir` - 루트 Next.js 앱 디렉토리 유지 (기본값: false)
- `--include-app-next-build-dir` - Next.js 앱용 빌드 디렉토리 유지 (기본값: false)
- `--include-app-next-dist-dir` - Next.js 앱용 정적 SPA 디렉토리 유지 (기본값: false)
- `--include-app-next-static-dir` - Next.js 앱용 정적 공개 에셋 디렉토리 유지 (기본값: false)
- `--include-app-next-nodemodules-dir` - Next.js 앱용 node modules 디렉토리 유지 (기본값: false)
- `--include-node-package` - 이름으로 node.js 패키지 유지 [이 플래그를 여러 번 사용할 수 있습니다]
- `--preserve-path` - 원래 이미지의 경로를 초기 상태로 유지 (실행될 때 선택한 컨테이너 이미지 파일에 대한 변경 사항은 폐기됨). [이 플래그를 여러 번 사용할 수 있습니다]
- `--preserve-path-file` - 원래 이미지의 경로를 원래 상태로 유지할 경로들이 포함된 파일 (실행될 때 선택한 컨테이너 이미지 파일에 대한 변경 사항은 폐기됨).
- `--path-perms` - 최적화된 이미지에서 경로 권한/사용자/그룹 설정 (형식: `target:octalPermFlags#uid#gid` ; 자세한 내용은 기본값이 아닌 USER FAQ 섹션 참조)
- `--path-perms-file` - 설정할 경로 권한이 있는 파일 (형식: `target:octalPermFlags#uid#gid` ; 자세한 내용은 기본값이 아닌 USER FAQ 섹션 참조)
- `--exclude-pattern` - 이미지에서 경로 패턴([Go의 Glob/Match](https://golang.org/pkg/path/filepath/#Match) 및 `\*\*`) 제외 (`--include-path`가 디렉토리를 유지하고 해당 디렉토리의 일부 파일을 제외/필터링해야 할 때 유용함)
- `--exclude-varlock-files` - var 및 run 락 디렉토리의 파일 제외 (기본값: true)
- `--exclude-mounts` - 이미지에서 마운트된 볼륨 제외 (기본값: true)
- `--label` - 런타임에 이미지를 분석하여 LABEL 오버라이드 또는 추가 [이 플래그를 여러 번 사용할 수 있습니다]
- `--volume` - 런타임에 이미지를 분석하여 VOLUME 추가 [이 플래그를 여러 번 사용할 수 있습니다]
- `--env` - 런타임에 대상 이미지를 분석하여 ENV 추가 [이 플래그를 여러 번 사용할 수 있습니다]
- `--env-file` - 런타임에 대상 이미지를 분석할 때 파일에서 여러 환경 변수 로드.
- `--workdir` - 런타임에 이미지를 분석하여 WORKDIR 오버라이드
- `--network` - 런타임에 이미지를 분석하여 기본 컨테이너 네트워크 설정 오버라이드
- `--expose` - 런타임에 이미지를 분석하여 추가 EXPOSE 지침 사용 [이 플래그를 여러 번 사용할 수 있습니다]
- `--link` - 런타임에 이미지를 분석하여 다른 컨테이너에 대한 링크 추가 [이 플래그를 여러 번 사용할 수 있습니다]
- `--hostname` - 런타임에 이미지를 분석하여 기본 컨테이너 호스트 이름 오버라이드
- `--etc-hosts-map` - 런타임에 이미지를 분석하여 /etc/hosts에 호스트-IP 매핑 추가 [이 플래그를 여러 번 사용할 수 있습니다]
- `--container-dns` - 런타임에 이미지를 분석하여 DNS 서버 추가 [이 플래그를 여러 번 사용할 수 있습니다]
- `--container-dns-search` - 런타임에 이미지를 분석하여 정규화되지 않은 호스트 이름에 대한 DNS 검색 도메인 추가 [이 플래그를 여러 번 사용할 수 있습니다]
- `--image-overrides` - 생성된 이미지에 런타임 오버라이드 저장 (값은 `all`이거나 오버라이드 유형의 쉼표로 구분된 목록: `entrypoint`, `cmd`, `workdir`, `env`, `expose`, `volume`, `label`). 런타임 값을 설정해야 하고 이를 최적화된 이미지에 유지(persists)하려는 경우 이 플래그를 사용하세요. 최적화된 이미지에서 이미지 값을 추가, 편집 또는 삭제만 하려면 `--new-\*` 또는 `--remove-\*` 플래그 중 하나를 사용하세요(아래 정의됨).
- `--continue-after` - 지속 모드 선택: `enter` | `signal` | `probe` | `exec` | `timeout-number-in-seconds` | `container.probe` (http 프로브가 비활성화된 경우의 기본값: `enter`). `probe`와 `exec`를 함께 선택할 수도 있습니다: `'probe&exec'` (쉘 명령어가 깨지는 것을 방지하기 위해 두 모드 주위에 따옴표를 사용하세요).
- `--dockerfile` - 최적화하기 전에 비대한(fat) 이미지를 빌드할 소스 Dockerfile 이름.
- `--tag-fat` - Dockerfile에서 빌드된 비대한 이미지의 사용자 지정 태그.
- `--cbo-add-host` - 이미지를 빌드할 때 사용할 /etc/hosts에 추가 호스트-IP 매핑 추가 (컨테이너 빌드 옵션).
- `--cbo-build-arg` - 빌드 타임 변수 추가 (컨테이너 빌드 옵션).
- `--cbo-label` - Dockerfile에서 빌드할 때 라벨 추가 (컨테이너 빌드 옵션).
- `--cbo-target` - 다단계 Dockerfile을 위해 빌드할 대상 스테이지 (컨테이너 빌드 옵션).
- `--cbo-network` - 빌드 타임에 RUN 지침에 사용할 네트워킹 모드 (컨테이너 빌드 옵션).
- `--cbo-cache-from` - 빌드 캐시에 이미지 추가 (컨테이너 빌드 옵션).
- `--cro-runtime` - 생성된 컨테이너와 함께 사용할 런타임 (컨테이너 런타임 옵션).
- `--cro-host-config-file` - 컨테이너를 실행할 때 사용할 Docker 호스트 구성 데이터(JSON 형식)를 로드할 파일. 설정 세부 정보는 `go-dockerclient` 패키지의 [HostConfig](https://pkg.go.dev/github.com/fsouza/go-dockerclient#HostConfig) 구조체 정의를 참조하세요. Slim은 seccomp 프로필을 생성하는 데 필요한 `SYS\_ADMIN`을 기능(capabilities) 목록에 자동으로 추가하고 컨테이너를 권한 상승(privileged) 모드로 실행합니다. 독립 실행형 빌드 또는 프로파일 명령어 플래그를 사용하여 지정된 호스트 설정 매개변수는 호스트 설정 파일의 값을 오버라이드합니다(볼륨 바인드는 병합됨).
- `--cro-sysctl` - 생성된 컨테이너에서 네임스페이스가 지정된 커널 매개변수 설정 (컨테이너 런타임 옵션).
- `--cro-shm-size` - 생성된 컨테이너의 /dev/shm에 대한 공유 메모리 크기 (컨테이너 런타임 옵션).
- `--use-local-mounts` - 대상 컨테이너 아티팩트 입력 및 출력을 위해 로컬 경로 마운트 (기본값: off)
- `--use-sensor-volume` - 사용할 센서 볼륨 이름 (자체 Slim 센서 볼륨을 관리하는 경우 Docker 볼륨 이름으로 설정).
- `--keep-tmp-artifacts` - 명령어가 완료될 때 임시 아티팩트 유지 (기본값: off).
- `--keep-perms` - 아티팩트 권한을 그대로 유지 (기본값: true)
- `--run-target-as-user` - Dockerfile의 USER로 (임시 컨테이너에서) 대상 앱 실행 (기본값: true)
- `--new-entrypoint` - 최적화된 이미지를 위한 새로운 ENTRYPOINT 지침
- `--new-cmd` - 최적화된 이미지를 위한 새로운 CMD 지침
- `--new-expose` - 최적화된 이미지를 위한 새로운 EXPOSE 지침
- `--new-workdir` - 최적화된 이미지를 위한 새로운 WORKDIR 지침
- `--new-env` - 최적화된 이미지를 위한 새로운 ENV 지침
- `--new-label` - 최적화된 이미지를 위한 새로운 LABEL 지침
- `--new-volume` - 최적화된 이미지를 위한 새로운 VOLUME 지침
- `--remove-volume` - VOLUME 지침 제거
- `--remove-env` - ENV 지침 제거
- `--remove-label` - LABEL 지침 제거
- `--remove-expose` - EXPOSE 지침 제거
- `--exec` - Docker exec를 통해 실행할 쉘 스크립트 스니펫
- `--exec-file` - Docker exec를 통해 실행할 쉘 스크립트 파일
- `--sensor-ipc-mode` - 센서 IPC 모드 선택: proxy | direct (컨테이너화된 CI/CD 환경에 유용함)
- `--sensor-ipc-endpoint` - 센서 IPC 엔드포인트 오버라이드
- `--rta-onbuild-base-image` - onbuild 베이스 이미지에 대한 런타임 분석 활성화 (기본값: false)
- `--rta-source-ptrace` - PTRACE 런타임 분석 소스 활성화 (기본값: true)
- `--image-build-engine` - 이미지 빌드 엔진 선택: `internal` | `docker` | `none` (`internal` - Docker를 사용하지 않고 출력 이미지 빌드 [기본 동작], `docker` - Docker를 사용하여 출력 이미지 빌드, `none` - 출력 이미지 빌드 안 함. 출력 이미지에 대한 `files.tar` 및 `Dockerfile` 아티팩트가 있는 아티팩트 디렉토리를 가리켜서 원하는 도구로 직접 빌드할 수 있음)
- `--image-build-arch` - 출력 이미지 빌드 아키텍처 선택 (OS 부분을 제외한 아키텍처에 표준 컨테이너 이미지 이름 사용)
- `--obfuscate-metadata` - 이미지 컴포넌트를 식별하기 더 어렵게 만들기 위해 표준 시스템 및 애플리케이션 메타데이터 난독화 (실험적 플래그, 난독화 첫 버전; [`Malicious Compliance`](https://kccnceu2023.sched.com/event/1Hybu/malicious-compliance-reflections-on-trusting-container-scanners-ian-coldwater-independent-duffie-cooley-isovalent-brad-geesaman-ghost-security-rory-mccune-datadog) KubeCon EU 2023 발표에서 영감을 받음)
- `--enable-mondel` - 센서 모니터가 해당 모니터에 의해 캡처된 이벤트를 기록/스트리밍할 수 있도록 모니터 데이터 이벤트 로그 활성화 (기본값: false)
대화형 CLI 프롬프트 모드에서는 `--target` 플래그를 사용하여 대상 이미지를 지정해야 하며, 전통적인 CLI 모드에서는 `--target` 플래그를 사용하거나 명령어의 마지막 값으로 대상 이미지 지정할 수 있습니다.
`--include-path` 옵션은 추가 파일과 디렉토리를 추가하여 최소화된 이미지를 사용자 지정하려는 경우에 유용합니다. `--include-path-file` 옵션을 사용하면 개행 문자로 구분된 파일에서 여러 포함 항목을 로드할 수 있습니다. 포함할 파일이 많은 경우 이 옵션을 사용하세요. `--include-path`와 `--include-path-file`의 포함 항목은 함께 결합됩니다. `--exclude-pattern` 플래그를 사용하여 포함하지 않아야 할 항목을 제어할 수도 있습니다.
`--continue-after` 옵션은 Slim 앱을 스크립팅해야 하는 경우에 유용합니다. `probe` 옵션을 선택하면 Slim은 HTTP 프로브 실행이 완료된 후 빌드 명령어 실행을 계속합니다. `exec` 옵션을 선택하면 Slim은 컨테이너 exec 쉘 명령어(`--exec-file` 또는 `--exec` 플래그를 사용하여 지정됨) 실행이 완료된 후 빌드 명령어 실행을 계속합니다. `timeout` 옵션을 선택하면 Slim은 아티팩트 수집을 시도하기 전에 대상 컨테이너가 60초 동안 실행되도록 허용합니다. `timeout` 문자열 대신 필요한 초 수를 전달하여 사용자 지정 타임아웃 값을 지정할 수 있습니다. `signal` 옵션을 선택하면 Slim 앱 프로세스에 `USR1` 신호를 보내야 합니다. `signal` 옵션은 Slim이 생성한 임시 컨테이너에 대해 자체 테스트를 실행하려는 경우에 유용합니다. 테스트 자동화 / CI/CD 파이프라인은 Slim 앱에 `USR1`을 전송하여 테스트 실행이 완료되었음을 Slim 앱에 알릴 수 있습니다.
여러 개의 `continue-after` 모드를 결합할 수도 있습니다. 현재는 `probe`와 `exec` 결합만 지원됩니다(`--continue-after` 플래그 값으로 `probe&exec` 또는 `exec&probe` 사용). 다른 조합도 작동할 수 있습니다. `probe`와 `signal`의 조합은 지원되지 않습니다.
`--include-shell` 옵션은 최소화된 컨테이너에 기본 쉘을 유지하는 간단한 방법을 제공합니다. 모든 쉘 명령어가 포함되는 것은 아닙니다. 추가 쉘 명령어나 기타 명령줄 유틸리티를 얻으려면 `--include-exe` 및/또는 `--include-bin` 옵션을 사용하세요. 추가 앱 및 바이너리에는 정적 분석 중에 수집되지 않는 비바이너리 종속성이 일부 누락될 수 있습니다. 이러한 추가 종속성을 위해 `--include-path` 및 `--include-path-file` 옵션을 사용하세요.
`--dockerfile` 옵션을 사용하면 소스 Dockerfile에서 직접 새로운 최소화된 이미지를 빌드할 수 있습니다. 이 플래그의 값으로 Dockerfile 이름을 전달하고, `build` 명령어의 마지막 파라미터로 docker 이미지 이름 대신 빌드 컨텍스트 디렉토리나 URL을 전달하세요: `slim build --dockerfile Dockerfile --tag my/custom\_minified\_image\_name .` 빌드 단계(비대한 이미지와 슬림 이미지가 빌드될 때)의 콘솔 출력을 보려면 `--show-blogs` 빌드 플래그를 추가하세요. 빌드 콘솔 출력은 대화형이 아니며 해당 빌드 단계가 완료된 후에만 출력됩니다. 빌드 과정에서 생성된 비대한 이미지의 이름에는 `.fat` 접미사가 붙습니다. 사용자 지정 이미지 태그를 지정하는 경우(`--tag` 플래그 사용) `.fat` 접미사는 태그의 이름 부분에 추가됩니다. 사용자 지정 태그를 제공하지 않으면 생성된 비대한 이미지 이름은 다음 형식을 갖습니다: `slim-tmp-fat-image..`. 최소화된 이미지 이름에는 해당 자동 생성된 컨테이너 이미지 이름에 `.slim` 접미사가 추가됩니다 (`slim-tmp-fat-image...slim`). `--dockerfile` 플래그 사용법을 보려면 이 [python 예제](https://github.com/slimtoolkit/examples/tree/master/python\_ubuntu\_18\_py27\_from\_dockerfile)를 살펴보세요.
`--use-local-mounts` 옵션은 Slim 센서가 대상 컨테이너에 추가되는 방식과 센서 아티팩트가 마스터로 다시 전달되는 방식을 선택하는 데 사용됩니다. 이 옵션을 활성화하면 센서 실행 파일을 추가하고 대상 컨테이너에서 아티팩트를 추출하기 위해 로컬 파일 시스템 볼륨 마운트를 사용하는 원래 Slim 앱 동작을 얻을 수 있습니다. 이 옵션은 Slim 자체가 Docker 컨테이너에서 실행되는 Dockerized 환경에서는 항상 예상대로 작동하지는 않습니다. 이 옵션이 비활성화된 경우(기본 동작) 센서를 마운트하기 위해 별도의 Docker 볼륨이 사용되며 센서 아티팩트는 대상 컨테이너에서 명시적으로 복사됩니다.
### `DEBUG` 명령어 옵션
- `--runtime` - 런타임 환경 유형 (값: `docker`, `k8s`; 기본값은 `docker`)
- `--debug-image` - 디버그 사이드카 컨테이너에 사용할 디버그 이미지 (이 플래그의 기본값은 `busybox`).
- `--list-debug-images` - 디버그 사이드카 컨테이너에 사용할 수 있는 디버그 이미지 목록 표시 (`--debug-image` 플래그용). 이 목록은 바로 사용할 수 있는 디버그 이미지 세트입니다. 다른 이미지들도 사용할 수 있습니다.
- `--target` - 대상 컨테이너 이름 또는 ID (`debug` 명령어의 명령줄 호출에서 마지막 파라미터로 제공될 수도 있음). 대상 컨테이너가 실행 중이어야 합니다. `docker run` 명령어를 사용하여 대상 컨테이너를 시작할 수 있습니다(또는 쿠버네티스 동등한 명령어).
- `--namespace` - 타겟팅할 네임스페이스 [k8s 런타임] (기본값은 `default`)
- `--pod` - 타겟팅할 Pod [k8s 런타임]
- `--cmd` - (선택 사항) 디버그 사이드카 컨테이너에 사용할 사용자 지정 CMD (또는 '--' 뒤에 사용자 지정 CMD 파라미터 전달).
- `--entrypoint` - (선택 사항) 디버그 사이드카 컨테이너에 사용할 사용자 지정 ENTRYPOINT.
- `--terminal` - 디버그 컨테이너에 대화형 터미널 연결 (기본값: true). 대화형 터미널이 활성화되지 않은 경우 `debug` 명령어가 종료될 때 디버그 컨테이너 출력이 화면에 인쇄됩니다.
- `--kubeconfig` - Kubeconfig 파일 위치 [k8s 런타임]
- `--workdir` - 디버그 사이드카 컨테이너에 사용할 사용자 지정 WORKDIR.
- `--env` - 디버그 사이드카 컨테이너에 추가할 환경 변수.
- `--run-as-target-shell` - 디버그 컨테이너에 대화형 터미널을 연결하고 마치 대상 컨테이너 환경에서 실행 중인 것처럼 쉘을 실행합니다.
- `--list-sessions` - 선택한 대상에 대한 모든 디버그 세션 나열 (k8s의 경우 pod 및 선택적 선택된 컨테이너, 다른 런타임의 경우 컨테이너).
- `--show-session-logs` - 선택한 디버그 세션에 대한 로그 표시 (k8s의 경우 네임스페이스, 포드, 대상 컨테이너 또는 디버그 세션 컨테이너 이름을 사용하고, 다른 런타임의 경우 디버그 세션 컨테이너 이름 사용).
- `--session` - 디버그 세션 컨테이너 이름 (디버그 세션 작업에 사용됨).
- `--connect-session` - 기존 디버그 세션에 연결.
- `--list-namespaces` - 사용 가능한 네임스페이스 이름 나열 (이 플래그만 단독으로 사용) [k8s 런타임].
- `--list-pods` - 선택한 네임스페이스에서 실행 중인 포드 이름 나열 (이 플래그만 단독으로 사용) [k8s 런타임].
- `--list-debuggable-containers` - 디버깅할 수 있는 활성 컨테이너의 컨테이너 이름 나열 (이 플래그만 단독으로 사용).
- `--list-debug-images` - 디버그 사이드카 컨테이너에 사용할 수 있는 디버그 이미지 나열 (이 플래그만 단독으로 사용).
- `--help` 도움말 표시 (기본값: false)
이 명령어에 대한 자세한 내용은 "`debug` 명령어를 사용한 디버깅" 섹션을 참조하세요.
### `RUN` 명령어 옵션
하나 이상의 컨테이너 실행
사용법: `slim [GLOBAL FLAGS] run [FLAGS] [IMAGE]`
플래그:
- `--target` - 실행할 대상 컨테이너 이미지. 명령어의 마지막 값으로 대상 컨테이너 이미지와 동일하게 지정합니다. 주로 플래그 이름을 선택해야 하는 대화형 프롬프트 모드에 사용됩니다.
- `--pull` - 실행하기 전에 대상 이미지를 풀합니다.
- `--docker-config-path` - Docker 설정 경로 (레지스트리 자격 증명을 가져오는 데 사용).
- `--registry-account` - 비공개 레지스트리에서 이미지를 풀할 때 사용하는 대상 레지스트리 계정.
- `--registry-secret` - 비공개 레지스트리에서 이미지를 풀할 때 사용하는 대상 레지스트리 비밀번호.
- `--show-plogs` - 이미지 풀 로그 표시.
- `--entrypoint` - 대상 이미지를 실행할 때 ENTRYPOINT 오버라이드.
- `--cmd` - 대상 이미지를 실행할 때 CMD 오버라이드.
- `--live-logs` - 컨테이너의 실시간 로그 표시 (--terminal과 함께 사용할 수 없음).
- `--terminal` - 컨테이너에 대화형 터미널 연결.
- `--publish` - 컨테이너 포트를 호스트 포트에 매핑 (형식 => port | hostPort:containerPort | hostIP:hostPort:containerPort | hostIP::containerPort ).
- `--rm` - 종료될 때 컨테이너 제거.
- `--detach` - 컨테이너를 시작하고 종료될 때까지 기다리지 않음.
### `MERGE` 명령어 옵션
두 개의 컨테이너 이미지를 병합합니다. 경량화된 이미지 병합에 최적화되어 있습니다.
플래그:
- `--image` - 병합할 이미지. 플래그 인스턴스의 위치가 병합 순서를 결정합니다. 이 명령어는 이 플래그의 두 인스턴스를 지원합니다.
- `--use-last-image-metadata` - 병합된 이미지에 마지막 이미지 메타데이터만 사용.
- `--tag` - 출력 이미지에 대한 사용자 지정 태그 (여러 개 지정 가능).
### `REGISTRY` 명령어 옵션
인증이 필요한 작업의 경우 Docker의 레지스트리 자격 증명을 재사용하거나(`docker login`을 먼저 수행한 다음 `registry` 명령어와 함께 `--use-docker-credentials` 플래그 사용), `--account` 및 `--secret` 플래그를 사용하여 인증 정보를 지정할 수 있습니다.
현재 하위 명령어: `pull`, `push`, `image-index-create`, `server`.
`copy`에 대한 자리표시자도 있지만 아직 아무 작업도 수행하지 않습니다. 기여하기 좋은 기회입니다 ;-)
공유 명령어 수준 플래그:
- `--use-docker-credentials` - 기본 Docker 설정 파일의 레지스트리 자격 증명 사용.
- `--account` - 레지스트리 자격 증명 계정.
- `--secret` - 레지스트리 자격 증명 비밀번호.
#### `PULL` 하위 명령어 옵션
사용법: `slim [GLOBAL FLAGS] registry [SHARED FLAGS] pull [FLAGS] [IMAGE]`
플래그:
- `--target value` - 대상 컨테이너 이미지 (이름 또는 ID) [$DSLIM\_TARGET]
- `--save-to-docker`- 풀한 이미지를 docker에 저장 (기본값: true) [$DSLIM\_REG\_PULL\_SAVE\_TO\_DOCKER]
#### `PUSH` 하위 명령어 옵션
사용법: `slim [GLOBAL FLAGS] registry [SHARED FLAGS] push [FLAGS] [IMAGE]`
플래그:
- `--docker` -- 로컬 docker 이미지 푸시.
- `--tar` -- 로컬 tar 파일에서 이미지 푸시.
- `--as` -- 푸시하기 전에 지정한 이름으로 선택한 이미지 태그 지정.
`slim registry push LOCAL\_DOCKER\_IMAGE\_NAME`은 `slim registry push --docker LOCAL\_DOCKER\_IMAGE\_NAME`의 단축키입니다.
일반적으로 대상 레지스트리에 적합한 이름을 갖도록 대상 이미지를 명시적으로 태그해야 합니다. `--as` 플래그는 푸시하는 동안 이미지에 태그를 지정하는 편리한 방법입니다. 다음은 로컬 Docker `nginx` 이미지를 로컬 레지스트리로 푸시하는 예입니다: `slim registry push --docker nginx --as localhost:5000/nginx`
`server` 하위 명령어를 사용하여 로컬 레지스트리를 생성할 수 있습니다. 자세한 내용은 아래의 `server` 하위 명령어 섹션을 참조하세요.
#### `COPY` 하위 명령어 옵션
사용법: `slim registry copy [SRC\_IMAGE] [DST\_IMAGE]`
참고: 현재는 자리표시자에 불과함 (추후 구현 예정)
#### `IMAGE-INDEX-CREATE` 하위 명령어 옵션
사용법: `slim registry image-index-create --image-index-name [MULTI-ARCH\_IMAGE\_TAG] --image-name [IMAGE\_ONE] --image-name [IMAGE\_TWO]`
플래그:
- `--image-index-name` - 사용할 이미지 인덱스 이름.
- `--image-name` - 이미지 인덱스에 포함할 대상 이미지 이름.
- `--as-manifest-list` - 기본 OCI 이미지 인덱스 유형 대신 매니페스트 목록 미디어 유형으로 이미지 인덱스 생성.
- `--dump-raw-manifest` - 생성된 이미지 인덱스의 원시 매니페스트 덤프.
- `--insecure-refs` - 안전하지 않은 레지스트리 연결에서 참조된 이미지 허용.
#### `SERVER` 하위 명령어 옵션
기본적으로 포트 5000에서 [OCI API 스펙](https://github.com/opencontainers/distribution-spec/blob/v1.0.1/spec.md)을 구현하는 서버를 시작합니다.
사용법: `slim [GLOBAL FLAGS] registry server [FLAGS]`
플래그:
- `--address` - 수신 대기할 레지스트리 서버 주소 (기본값: `0.0.0.0`)
- `--port` - 레지스트리 서버 포트 (기본값: 5000)
- `--https` - HTTPS 사용.
- `--cert-path` - HTTPS와 함께 사용할 인증서 경로 (autocert를 사용하지 않는 경우).
- `--key-path` - HTTPS와 함께 사용할 키 경로 (autocert를 사용하지 않는 경우).
- `--domain` - 레지스트리 서버에 사용할 도메인 (인증서 획득용). 레지스트리가 인터넷에서 액세스 가능한 경우에만 작동합니다 (자세한 내용은 `autocert` Go 문서 참조).
- `--referrers-api` - [참조자 API 엔드포인트](https://github.com/opencontainers/distribution-spec/blob/v1.1.0-rc3/spec.md#enabling-the-referrers-api) 활성화 (OCI 1.1+). 기본적으로 활성화됨 (비활성화하려면 `false`로 설정).
### `VULNERABILITY` 명령어 옵션
사용법: `slim [GLOBAL FLAGS] vulnerability [SHARED FLAGS] [SUBCOMMAND] [FLAGS]`
현재 하위 명령어:
\* `epss` - 대상 취약점에 대한 EPSS 정보를 가져오거나 선택한 취약점 필터를 기반으로 가져옵니다.
공유 명령어 수준 플래그:
- `--cve` - 대상 취약점 CVE ID (여러 취약점을 대상으로 지정하기 위해 여러 번 지정할 수 있음).
#### `EPSS` 하위 명령어 옵션
사용법: `slim [GLOBAL FLAGS] vulnerability [SHARED FLAGS] epss [FLAGS]`
플래그:
- `--op` - EPSS 작업 (`lookup` | `list`).
- `--date` - EPSS 정보 날짜 (YYYY-MM-DD 형식). `lookup` 및 `list` 작업과 함께 작동합니다.
- `--with-history` - 과거 데이터가 포함된 EPSS 결과 반환. `lookup` 및 `list` 작업과 함께 작동합니다.
- `--limit` - 반환되는 레코드 수 제한.
- `offset` - 레코드를 반환하기 시작할 오프셋.
- `filter-cve-id-pattern` - 'CVE ID 패턴' EPSS 목록 작업 필터.
- `filter-days-since-added` - '추가된 이후 경과된 일수' EPSS 목록 작업 필터.
- `filter-score-gt` - '점수가 더 큼' EPSS 목록 작업 필터.
- `filter-score-lt` - '점수가 더 작음' EPSS 목록 작업 필터.
- `filter-percentile-gt` - '백분위수가 더 큼' EPSS 목록 작업 필터.
- `filter-percentile-lt` - '백분위수가 더 작음' EPSS 목록 작업 필터.
- `filter-order-records` - '반환된 레코드 정렬' EPSS 목록 작업 필터 ('score-desc' | 'score-asc' | 'percentile-desc' | 'percentile-asc').
예시:
\* `slim --quiet vulnerability --cve CVE-2021-21315 epss`
\* `slim --output-format=json vulnerability --cve CVE-2021-21315 epss`
\* `slim --quiet --output-format=json vulnerability --cve CVE-2021-21315 --cve CVE-2023-49070 epss`
\* `slim --quiet vulnerability --cve CVE-2021-21315 epss --with-history --date 2022-12-13`
\* `slim --quiet vulnerability epss --op list --date 2024-01-05`
\* `slim --quiet vulnerability epss --op list --filter-cve-id-pattern 2023 --filter-score-gt 0.92 --limit 2 --offset 3`
## 컨테이너 환경에서 실행하기
현재 버전의 Slim은 컨테이너 내부에서 실행할 수 있습니다. 컨테이너화된 환경에서 실행 중인지 감지하려고 시도하지만, `--in-container` 전역 플래그를 사용하여 Slim에 명시적으로 알릴 수도 있습니다.
컨테이너 내에서 직접 Slim을 실행하거나 컨테이너화된 환경에서 Slim 컨테이너 이미지를 사용할 수 있습니다. Slim 컨테이너 이미지를 사용하는 경우 Docker 데몬과 통신할 수 있도록 Docker IPC 정보가 설정된 상태로 실행해야 합니다. 가장 일반적인 방법은 Docker 유닉스 소켓을 Slim 앱 컨테이너에 마운트하는 것입니다. 일부 컨테이너화된 환경(Gitlab 및 `dind` 서비스 등)은 Docker 유닉스 소켓을 노출하지 않을 수 있으므로, Docker와 통신하는 데 사용되는 환경 변수(예: `DOCKER\_HOST`)가 Slim 앱 컨테이너로 전달되도록 해야 합니다. 이러한 환경 변수가 로컬 호스트 이름을 참조하는 경우 해당 이름을 교체하거나 `--etc-hosts-map` 플래그를 사용하여 Slim 앱에 알려야 합니다. 이러한 환경 변수가 로컬 파일을 참조하는 경우, 해당 로컬 파일(예: TLS 인증서 검증용 파일)을 임시 컨테이너에 복사하여, 해당 임시 컨테이너가 데이터 컨테이너로 사용되어 Slim 앱 컨테이너가 파일에 액세스할 수 있도록 해야 합니다.
Slim 앱이 컨테이너에서 실행되면 실행 상태를 별도의 Docker 볼륨에 저장하려고 시도합니다. 볼륨이 존재하지 않으면 생성을 시도합니다(기본값은 `slim-state`). 전역 `--archive-state` 플래그를 사용하여 다른 상태 볼륨을 선택하거나 이 동작을 완전히 비활성화할 수 있습니다. 상태 아카이빙 기능을 사용하지 않고 Slim 앱 실행 상태(`seccomp` 및 `AppArmor` 프로필 포함)를 유지하려면 Slim 앱 컨테이너의 `/bin/.slim-state` 디렉토리에 매핑되는 자체 볼륨을 마운트할 수 있습니다.
기본적으로 Slim 앱은 아직 존재하지 않는 경우 센서를 위한 Docker 볼륨을 생성하려고 시도합니다. 컨테이너화된 환경에서 이 동작을 지원하지 않는 경우 볼륨을 별도로 생성하고 `--use-sensor-volume` 플래그를 사용하여 그 이름을 Slim 앱에 전달할 수 있습니다.
컨테이너화된 버전의 Slim 앱을 사용하는 기본 예시는 다음과 같습니다:
`docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock dslim/slim build your-docker-image-name`
`dind` `.gitlab-ci.yml` 설정 파일에 대한 GitLab 예시는 다음과 같습니다:
`docker run -e DOCKER\_HOST=tcp://$(grep docker /etc/hosts | cut -f1):2375 dslim/slim build your-docker-image-name`
`remote docker` `.circleci/config.yml` 설정 파일에 대한 CircleCI 예시는 다음과 같습니다(`setup\_remote\_docker` 단계 후에 사용됨):
```bash
docker create -v /dcert\_path --name dcert alpine:latest /bin/true
docker cp $DOCKER\_CERT\_PATH/. dcert:/dcert\_path
docker run --volumes-from dcert -e DOCKER\_HOST=$DOCKER\_HOST -e DOCKER\_TLS\_VERIFY=$DOCKER\_TLS\_VERIFY -e DOCKER\_CERT\_PATH=/dcert\_path dslim/slim build your-docker-image-name
```
다양한 CI/CD 서비스는 메인 앱이 Slim이 생성한 임시 컨테이너에 내장된 센서 앱과 통신하는 능력에 영향을 미칠 수 있는 다양한 제약 조건을 부과하는 컨테이너화된 환경 설계를 가지고 있습니다. `--sensor-ipc-mode` 및 `--sensor-ipc-endpoint` 플래그의 값을 조정해 보세요. Márton Kodok의 이 [`Google Cloud Build`](https://medium.com/google-cloud/integrating-dockerslim-container-minify-step-on-cloud-build-64da29fd58d1) 블로그 게시물은 두 플래그 모두에 대한 좋은 참고 자료입니다.
### `\*-file` 플래그 사용하기
- 파일 경로를 허용하는 여러 플래그가 있습니다(`--include-path-file`, `--compose-file`, `--http-probe-cmd-file` 등). Slim의 컨테이너화된 버전을 사용할 때는 Slim 앱 컨테이너가 그렇지 않으면 참조된 파일에 액세스할 수 없으므로 참조된 경로 또는 파일 경로 자체의 위치를 볼륨 마운트해야 합니다.
## CI/CD 통합
### Jenkins에 Slim 통합
#### 사전 요구 사항:
- 원하는 클라우드 플랫폼(AWS, Azure, GCP)을 통해 Ubuntu OS가 설치된 가상 머신(예: EC2 Instance, Azure VM, GCE)을 생성하고, 머신에 SSH로 접속하여 머신 패키지를 업데이트하고 docker를 설치합니다. 이 단계의 예시는 AWS EC2 인스턴스를 실행하는 것을 가정하여 아래에 강조되어 있습니다.
```
sudo apt update -y
```
```
sudo apt install docker -y
```
```
sudo systemctl start docker
```
```
sudo usermod -aG docker ec2-user
```
- [Jenkins 문서](https://github.com/jenkinsci/docker/blob/master/README.md)에 규정된 대로 docker를 사용하여 가상 머신에 Jenkins를 설치합니다. 이 단계는 [DockerHub에서 Jenkins 이미지](https://hub.docker.com/r/jenkins/jenkins)를 풀하고, 포트 8080을 통해 Jenkins를 컨테이너로 실행하며, 호스트 머신에 명시적인 docker 볼륨을 생성하여 Jenkins 데이터를 유지합니다. AWS EC2 인스턴스를 실행하는 경우, 인스턴스 보안 그룹 규칙에 인터넷 프로토콜(IP) 주소만 Jenkins 서버에 액세스할 수 있도록 허용하는 포트 8080의 TCP 규칙을 생성하세요.
```
docker run -p 8080:8080 -p 50000:50000 -d -v jenkins\_home:/var/jenkins\_home jenkins/jenkins:lts
```
- 이제 Jenkins가 가상 머신 내에서 컨테이너화된 환경으로 실행되고 있으므로, Jenkins 컨테이너에서 docker를 사용할 수 있도록 해야 합니다. 가상 머신의 docker unix socket을 jenkins 컨테이너에 바인드 마운트하여 이를 수행할 수 있습니다. 이 단계를 수행하려면 실행 중인 jenkins 컨테이너를 중지해야 하며, docker ps 명령어를 사용하여 jenkins 컨테이너 ID를 찾을 수 있습니다. 실행할 명령어는 아래에 강조되어 있습니다. 이 단계는 Jenkins 컨테이너에서 docker를 사용할 수 있게 하므로 매우 중요하며, docker를 사용하여 추가 단계에서 사용할 Slim 이미지를 풀할 수 있습니다.
```
docker ps
```
```
docker stop [jenkins\_container\_id]
```
```
docker run -p 8080:8080 -p 50000:50000 -d \
-v jenkins\_home:/var/jenkins\_home \
-v /var/run/docker.sock:/var/run/docker.sock \
-v $(which docker):/usr/bin/docker jenkins/jenkins:lts
```
- Jenkins가 docker 명령어를 실행하고 컨테이너에서 [Slim 공식 이미지](https://hub.docker.com/r/dslim/docker-slim)를 풀할 수 있도록 새로운 jenkins 컨테이너에서 Docker 권한을 활성화합니다. 이렇게 하려면 root 사용자로 Jenkins 컨테이너에 들어가야 합니다. docker ps 명령어를 사용하여 jenkins 컨테이너 ID를 찾을 수 있으며, 실행할 명령어는 다음과 같습니다:
```
docker exec -u 0 -it [jenkins\_container\_id] bash
```
```
chmod 666 /var/run/docker.sock
```
```
docker pull dslim/slim
```
#### Jenkinsfile Slim 스테이지
위의 사전 요구 사항 단계를 완료했다면, Jenkinsfile 스테이지에 강조되어야 하는 아래의 스니펫 스테이지를 통해 Slim을 사용하여 Docker 이미지를 빌드하고 이미지 크기를 최소화할 수 있습니다.
```
stage("Build and Slim Docker Image") {
steps {
script {
echo "building and slimming docker image..."
sh 'docker build -t IMAGE\_NAME:$BUILD\_NUMBER .'
sh 'docker run --rm -v /var/run/docker.sock:/var/run/docker.sock dslim/slim \
build --target IMAGE\_NAME:$BUILD\_NUMBER --tag IMAGE\_NAME:slim-$BUILD\_NUMBER \
exit'
}
}
}
```
- 위의 스니펫 스테이지는 사용자 지정을 허용합니다. 이미지 이름인 `IMAGE\_NAME`을 원하는 이미지 이름으로 교체해야 하며, 환경 변수 태그인 `$BUILD\_NUMBER`는 jenkins 파이프라인이 실행될 때마다 Jenkins가 할당하는 고유한 증가하는 숫자를 나타냅니다.
- docker build 명령어는 Dockerfile에서 애플리케이션의 Docker 이미지를 빌드합니다.
- docker run 명령어는 docker unix socket을 통해 비대화형 모드로 Slim을 실행하고, 빌드된(대상) 이미지인 `IMAGE\_NAME:$BUILD\_NUMBER`를 최소화하며, 이미지/태그 `IMAGE\_NAME:slim-$BUILD\_NUMBER`를 사용하여 새로운 슬림화된 이미지로 조정합니다.
- Jenkinsfile의 docker tag/push 스테이지 전과 build/test 아티팩트 후에 Slim 스테이지를 배치해야 합니다. 샘플 nodejs 애플리케이션에 대한 파이프라인 예시가 아래에 강조되어 있습니다. 첫 번째 스테이지는 애플리케이션의 아티팩트를 테스트하고 빌드합니다. 두 번째 스테이지는 Docker 이미지와 Docker 이미지의 슬림화된 버전을 빌드합니다. 세 번째 스테이지는 슬림화된 Docker 이미지에 DockerHub 계정 원격 리포지토리 태그를 지정하고 이미지를 원격 리포지토리에 푸시합니다.
```
pipeline {
agent any
stages {
stage("building nodejs app") {
steps{
script {
echo "building nodejs app..."
sh 'npm run test'
sh 'npm pack'
}
}
}
stage("Build and Slim Docker Image") {
steps {
script {
echo "building and slimming docker image..."
sh 'docker build -t node\_alpine:$BUILD\_NUMBER .'
sh 'docker run --rm -v /var/run/docker.sock:/var/run/docker.sock dslim/slim \
build --target node\_alpine:$BUILD\_NUMBER --tag node\_alpine:slim-$BUILD\_NUMBER \
exit'
}
}
}
stage("Push Slim Image to Regristy") {
steps {
script {
echo 'pushing image to docker regristry...'
withCredentials([usernamePassword(credentialsId: 'docker-hub-credentials', passwordVariable: 'PASS', usernameVariable: 'USER')]) {
sh 'docker tag node\_alpine:slim-$BUILD\_NUMBER $USER/node\_alpine:slim-$BUILD\_NUMBER'
sh 'echo $PASS | docker login -u $USER --password-stdin'
sh 'docker push $USER/node\_alpine:slim-$BUILD\_NUMBER'
}
}
}
}
}
}
```
### Github Actions에 Slimtoolkit 통합
#### Github Action
CI/CD 워크플로우에 SlimToolkit을 Github Actions에 통합하는 것은 [Docker-Slim Github Action](https://github.com/marketplace/actions/docker-slim-github-action)을 사용하는 것을 포함합니다. 이 액션(아래 스니펫)은 워크플로우에서 대상 docker 이미지인 `IMAGE\_NAME:latest`를 최소화하여 크기를 줄이고 새로운 슬림화된 이미지를 `IMAGE\_NAME:slim`으로 조정합니다.
```
# Slim it!
- uses: kitabisa/docker-slim-action@v1
env:
DSLIM\_HTTP\_PROBE: false
with:
target: IMAGE\_NAME:latest
tag: "slim"
```
#### Github Actions Slim 워크플로우
[Docker Build/Push Github Action](https://github.com/docker/build-push-action) 뒤에, 그리고 [Docker Login Github Action](https://github.com/docker/login-action) 및 docker tag/push 명령어 앞에 액션을 삽입하여 워크플로우에 Docker-Slim Github Action을 통합할 수 있습니다. 사용자 지정된 예시 워크플로우가 아래에 강조되어 있습니다. 워크플로우의 환경 변수 태그인 `${github.run\_number}`는 워크플로우가 실행될 때마다 Github Actions가 할당하는 고유한 증가하는 숫자를 나타냅니다.
```
# Build the Docker image first
- uses: docker/build-push-action@v4
with:
push: false
tags: IMAGE\_NAME:${{github.run\_number}}
# Slim the Image
- uses: kitabisa/docker-slim-action@v1
env:
DSLIM\_HTTP\_PROBE: false
with:
target: IMAGE\_NAME:${{github.run\_number}}
tag: "slim-${{github.run\_number}}"
# Docker Hub Login
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKERHUB\_USERNAME }}
password: ${{ secrets.DOCKERHUB\_TOKEN }}
# Push to the registry
- run: |
docker tag IMAGE\_NAME:slim-${{github.run\_number}} ${{ secrets.DOCKERHUB\_USERNAME }}/IMAGE\_NAME:slim-${{github.run\_number}}
docker push ${{ secrets.DOCKERHUB\_USERNAME }}/IMAGE\_NAME:slim-${{github.run\_number}}
```
위의 워크플로우는 네 가지 단계를 나타냅니다:
- 이미지 이름/태그 `IMAGE\_NAME:${{github.run\_number}}`로 docker 이미지를 빌드하기 위한 [Docker Build/Push Github Action](https://github.com/docker/build-push-action). `IMAGE\_NAME`을 원하는 이미지 이름으로 교체해야 합니다. 이 액션은 빌드된 이미지를 푸시하지 않도록 false 옵션을 가져야 합니다(컨테이너 레지스트리에 푸시하기 전에 이미지가 슬림화/최소화되어야 하므로).
- 대상 이미지 `IMAGE\_NAME:${{github.run\_number}}`를 최소화하는 Docker-Slim Github Action. 이 액션은 "slim-${{github.run\_number}}" 태그를 가지며 슬림화/최소화된 docker 이미지에 이 태그를 추가하여 이미지 이름/태그가 `IMAGE\_NAME:slim-${{github.run\_number}}`가 되도록 합니다.
- DockerHub 컨테이너 레지스트리 계정에 로그인하는 Docker Login Github Action. 워크플로우용으로 지정된 github 리포지토리에 시크릿으로 DockerHub 사용자 이름과 개인용 액세스 토큰을 저장해야 합니다. 컨테이너 레지스트리가 DockerHub가 아닌 경우, 원하는 컨테이너 레지스트리에 로그인하는 사용 사례에 대해 [Docker Login Github Action 문서](https://github.com/docker/login-action)를 확인하세요.
- 슬림화된 이미지에 슬림화된 이미지와 동일한 이름(`IMAGE\_NAME`)일 수 있는 DockerHub 계정 원격 리포지토리 이름을 태그로 지정하기 위한 docker tag 명령어; 슬림화된 이미지를 Dockerhub 계정 원격 리포지토리에 푸시하기 위한 docker push 명령어.
## DOCKER 연결 옵션
Docker 연결 옵션을 지정하지 않으면 Slim 앱은 Docker 유닉스 소켓(`/var/run/docker.sock`) 또는 다음 환경 변수를 찾습니다: `DOCKER\_HOST`, `DOCKER\_TLS\_VERIFY` (선택 사항), `DOCKER\_CERT\_PATH` (`DOCKER\_TLS\_VERIFY`가 `"1"`로 설정된 경우 필수). `DOCKER\_HOST` 환경 변수는 유닉스 소켓 주소를 가리키는 데 사용할 수 있습니다(기본 유닉스 소켓이 없는 경우). 이는 Docker Desktop을 사용하고 있고 기본 유닉스 소켓을 생성하도록 Docker Desktop을 설정하지 않은 경우에 유용합니다.
Docker 환경 변수가 TLS를 사용하고 Docker 인증서를 검증하도록 설정되어 있지만(기본 동작), TLS 검증을 비활성화하려는 경우 `--tls-verify`를 false로 설정하여 TLS 검증 동작을 오버라이드할 수 있습니다:
`slim --tls-verify=false build my/sample-node-app-multi`
다음 플래그를 사용하여 모든 Docker 연결 옵션을 오버라이드할 수 있습니다: `--host`, `--tls`, `--tls-verify`, `--tls-cert-path`. 이 플래그들은 표준 Docker 옵션(및 환경 변수)에 해당합니다. `--host` 플래그를 사용하여(`DOCKER\_HOST`와 유사하게) 유닉스 소켓을 가리킬 수도 있습니다(예: `--host=unix:///var/run/docker.sock`).
검증과 함께 TLS를 사용하려면:
`slim --host=tcp://192.168.99.100:2376 --tls-cert-path=/Users/youruser/.docker/machine/machines/default --tls=true --tls-verify=true build my/sample-node-app-multi`
검증 없이 TLS를 사용하려면:
`slim --host=tcp://192.168.99.100:2376 --tls-cert-path=/Users/youruser/.docker/machine/machines/default --tls=true --tls-verify=false build my/sample-node-app-multi`
Docker 환경 변수가 설정되어 있지 않고 Docker 연결 옵션을 지정하지 않으면 Slim은 기본 유닉스 소켓을 사용하려고 시도합니다.
### DOCKER DESKTOP
Docker Desktop을 사용하는 경우 기본 유닉스 소켓(`/var/run/docker.sock`)이 설정되어 있지 않을 수 있습니다. 기본적으로 Docker Desktop은 `~/.docker/run/docker.sock`을 유닉스 소켓으로 사용합니다.
`--host` 또는 `DOCKER\_HOST`를 사용하여 Docker Desktop의 유닉스 소켓을 가리키거나, 기본/전통적인 유닉스 소켓을 생성하도록 Docker Desktop을 설정할 수 있습니다((`/var/run/docker.sock` 심볼릭 링크를 수동으로 생성하는 것도 방법입니다).
기본 유닉스 소켓을 생성하도록 Docker Desktop을 설정하려면 UI를 열고 `Settings -> Advanced`로 이동하여 `Enable default Docker socket (Requires password)` 옵션을 체크해야 합니다.
### COLIMA
Docker Desktop과 유사하지만, 소켓이 `unix://${HOME}/.colima//docker.sock`을 사용하도록 설정되어야 합니다.
## HTTP 프로브 명령어
HTTP 프로브가 활성화된 경우(참고: 기본적으로 활성화되어 있음) 기본적으로 모든 노출된 포트에서 HTTP를 통해 `GET /`을 실행한 다음 HTTPS를 통해 실행합니다. `--http-probe-cmd` 및 `--http-probe-cmd-file` 옵션을 사용하여 추가 명령어를 추가할 수 있습니다.
HTTP 프로빙을 비활성화하려면 `--http-probe` 플래그를 false로 설정하세요(예: `--http-probe=false`). `--http-probe-off` 플래그를 사용하여 동일한 작업을 수행할 수도 있습니다(매개변수 없이 플래그만 사용).
`--http-probe-cmd` 옵션은 크롤링(기본값은 false), 프로토콜, 메서드(기본값은 GET), 리소스(경로 및 쿼리 문자열) 등 일부 또는 모든 HTTP 명령어 옵션을 선택하여 소수의 간단한 명령어를 지정하려는 경우에 좋습니다.
사용자 지정 HTTP 프로브 명령어만 사용하고 제공한 명령어 목록에 기본 `GET /` 명령어가 추가되지 않도록 하려면 사용자 지정 HTTP 프로브 명령어를 지정할 때 `--http-probe`를 false로 설정해야 합니다. 이 불일치는 혼란을 줄이기 위해 향후 릴리스에서 해결될 예정입니다.
가능한 필드 조합:
\* `/path` - `GET /path` 실행
\* `crawl:/path` - `GET /path`를 실행한 다음 대상 페이지가 참조하는 페이지 크롤링
\* `post:/path` - `POST /path` 실행
\* `crawl:get:/path` - `GET /path`를 실행한 다음 대상 페이지가 참조하는 페이지 크롤링
\* `https:get:/path` - https에서만 `GET /path` 실행
\* `crawl:http:get:/path` - `GET /path`를 실행한 다음 대상 페이지가 참조하는 페이지 크롤링
다음은 몇 가지 예시입니다:
두 개의 추가 프로브 명령어 추가: `GET /api/info` 및 `POST /submit` (http를 먼저 시도한 다음 https 시도):
`slim build --show-clogs --http-probe-cmd /api/info --http-probe-cmd POST:/submit my/sample-node-app-multi`
하나의 추가 프로브 명령어 추가: `POST /submit` (http만 사용):
`slim build --show-clogs --http-probe-cmd http:POST:/submit my/sample-node-app-multi`
`--http-probe-cmd-file` 옵션은 명령어가 많거나 추가 HTTP 명령어 옵션을 선택하려는 경우에 좋습니다.
사용 가능한 HTTP 명령어 옵션:
\* `method` - 사용할 HTTP 메서드
\* `resource` - 대상 리소스 URL
\* `port` - 포트 번호
\* `protocol` - `http`, `https`, `http2`, `http2c` (http2의 평문 버전), `ws`, `wss` (보안 웹소켓)
\* `headers` - 열로 구분된 키/값 쌍 문자열 배열 (예: "Content-Type: application/json")
\* `body` - 문자열 형태의 요청 본문
\* `body\_file` - 제공된 파일에서 로드된 요청 본문
\* `username` - 기본 인증에 사용할 사용자 이름
\* `password` - 기본 인증에 사용할 비밀번호
\* `crawl` - 대상을 크롤링할지 여부를 나타내는 부울 (참조된 모든 리소스 방문)
다음은 프로브 명령어 파일 예시입니다:
`slim build --show-clogs --http-probe-cmd-file probeCmds.json my/sample-node-app-multi`
`probeCmds.json`의 명령어:
```
{
"commands":
[
{
"resource": "/api/info"
},
{
"method": "POST",
"resource": "/submit"
},
{
"procotol": "http",
"resource": "/api/call?arg=one"
},
{
"protocol": "http",
"method": "POST",
"resource": "/submit2",
"body": "key=value"
},
{
"protocol": "http",
"method": "POST",
"resource": "/submit3",
"body\_file": "mydata.json",
"headers": ["Content-Type: application/json"]
}
]
}
```
HTTP 프로브 명령어 파일 경로는 상대 경로(현재 작업 디렉토리 기준)이거나 절대 경로일 수 있습니다.
각 HTTP 프로브 호출에 대해 Slim은 호출 상태를 출력합니다. 예시: `info=http.probe.call status=200 method=GET target=http://127.0.0.1:32899/ attempt=1 error=none`.
Slim이 테스트 컨테이너를 시작할 때 출력하는 컨테이너 정보 메시지의 `target.port.list` 필드를 사용하여 자체 외부 HTTP 요청을 실행할 수 있습니다: `slim[build]: info=container name= id= target.port.list=[] target.port.info=[]`. 예시: `slim[build]: info=container name=slimk\_42861\_20190203084955 id=aa44c43bcf4dd0dae78e2a8b3ac011e7beb6f098a65b09c8bce4a91dc2ff8427 target.port.list=[32899] target.port.info=[9000/tcp => 0.0.0.0:32899]`. 이 정보를 사용하여 `curl` 또는 기타 HTTP 요청 생성 도구를 실행할 수 있습니다: `curl http://localhost:32899`.
현재 버전에는 실험적인 `크롤링(crawling)` 기능도 포함되어 있습니다. 기본 HTTP 프로브에 대해 이 기능을 활성화하려면 `--http-probe-crawl` 플래그를 사용하세요. 명령어 파일의 HTTP 프로브 명령어에 대해 `crawl` 부울 필드를 사용하여 활성화할 수도 있습니다.
`크롤링`이 활성화되면 HTTP 프로브는 대상 엔드포인트에서 찾은 링크를 따라가는 웹 크롤러처럼 작동합니다.
Swagger/OpenAPI 스펙을 기반으로 한 프로브는 또 다른 실험적 기능입니다. 이 기능은 두 가지 새로운 플래그를 도입합니다:
\* `http-probe-apispec` - 값: `:`
\* `http-probe-apispec-file` - 값: ``
`--http-probe-exec` 및 `--http-probe-exec-file` 옵션을 사용하여 http 프로브가 실행될 때 사용자가 제공한 명령어를 실행할 수 있습니다. 이 예시는 http 프로브가 실행될 때 Slim이 생성한 임시 컨테이너에 대해 `curl`을 실행할 수 있는 방법을 보여줍니다.
`slim build --http-probe-exec 'curl http://localhost:YOUR\_CONTAINER\_PORT\_NUM/some/path' --publish-port YOUR\_CONTAINER\_PORT\_NUM your-container-image-name`
## 최소화된 컨테이너 디버깅하기
### `debug` 명령어를 사용한 디버깅
현재 버전의 `debug` 명령어는 매우 기본적이며 유용한 기능이 몇 가지 부족합니다. Docker 또는 Kubernetes에서 실행 중인 컨테이너를 디버깅하는 데 도움이 됩니다(Kubernetes에서 컨테이너를 디버깅해야 하는 경우 `--runtime` 플래그를 사용하고 `k8s`로 설정하세요).
기본적으로 `debug` 명령어는 디버거 사이드카 이미지를 디버깅 대상 컨테이너에 연결할 때 대화형 터미널을 제공합니다. 향후 버전에서는 대상과 다양한 상호 작용 모드를 가질 수 있게 될 것입니다.
#### 디버그 이미지
어떤 컨테이너 이미지든 디버그 이미지로 사용할 수 있지만, 선택할 수 있는 사전 선택된 디버그 이미지 목록이 있습니다.
`--list-debug-images`를 사용하여 사전 선택된 모든 디버그 이미지를 나열할 수 있으며, 대화형 프롬프트 모드를 사용하는 경우 `--debug-image` 플래그에 대한 자동 완성 드롭다운 메뉴가 제공됩니다.
현재 디버그 이미지 목록은 다음과 같습니다:
\* `cgr.dev/chainguard/slim-toolkit-debug:latest` - Chainguard에서 생성한 범용 SlimToolkit 디버그 이미지
\* `cgr.dev/chainguard/wolfi-base:latest` - 기본 경량 Wolfi 이미지
\* `busybox:latest` - 일반적인 유닉스 유틸리티가 포함된 경량 이미지
\* `nicolaka/netshoot` - 네트워크 트러블슈팅 만능 컨테이너
\* `lightruncom/koolkits:node` - Node.js 애플리케이션용 디버그 이미지
\* `lightruncom/koolkits:python` - Python 애플리케이션용 디버그 이미지
\* `lightruncom/koolkits:golang` - Go 애플리케이션용 디버그 이미지
\* `lightruncom/koolkits:jvm` - Java 애플리케이션용 디버그 이미지
\* `digitalocean/doks-debug:latest` - 쿠버네티스 트러블슈팅 디버그 이미지
\* `public.ecr.aws/zinclabs/debug-ubuntu-base:latest` - 일반적인 디버깅 유틸리티가 포함된 이미지
#### 컨테이너를 디버깅하는 단계 (Kubernetes 런타임)
1. 디버깅하려는 대상 환경이 실행 중인지 확인합니다(예시 k8s 매니페스트는 Chainguard의 최소 nginx 이미지로 포드를 생성하며 쉘이 없음):
```bash
>> kubectl apply -f examples/k8s\_nginx\_cgr/manifest.yaml
```
2. 디버그 명령어 실행:
```bash
>> slim debug --runtime=k8s --pod=example-pod example-container
```
또는
```bash
>> slim debug --runtime=k8s --pod=example-pod --target=example-container
```
이제 `slim`에 의해 시작된 디버그 컨테이너에 대한 대화형 쉘이 생기며 일반적인 쉘 명령어를 입력할 수 있습니다.
기본적으로 `debug` 명령어는 대화형 터미널을 디버깅된 컨테이너에 연결하고 마치 대상 컨테이너 환경에서 실행 중인 것처럼 쉘을 실행하므로, 직접 연결된 것처럼 대상 컨테이너의 파일 시스템을 볼 수 있습니다(`proc` 파일 시스템을 거칠 필요가 없음). `--run-as-target-shell`을 사용하여 이 동작을 변경할 수 있습니다(기본값은 true). 예를 들어, 이 호출은 더 전통적인 방식으로 디버그 컨테이너에 연결합니다: `slim debug --runtime=k8s --run-as-target-shell=false example-container`
또한 대화형 `prompt` 모드(`slim`을 명령줄 파라미터 없이 실행할 때)를 사용하는 경우 `--target`, `--namespace`, `--pod`, `--session` 등 여러 플래그에 대한 자동 완성 동작을 얻을 수 있습니다.
이미지를 디버깅할 때마다 `slim`에는 이를 나타내는 세션이 생성됩니다. 기존 활성 디버그 세션에 다시 연결할 수 있으며 사용 가능한 모든 세션에서 로그를 가져올 수 있습니다.
#### 컨테이너를 디버깅하는 단계 (Docker 런타임)
1. 디버깅하려는 대상 컨테이너 시작:
```bash
>> docker run -it --rm -p 80:80 --name mycontainer nginx
```
2. 디버그 명령어 실행:
```bash
>> slim debug mycontainer
```
또는
```bash
>> slim debug --target=mycontainer
```
이제 `slim`에 의해 시작된 디버그 컨테이너에 대한 대화형 쉘이 생기며 일반적인 쉘 명령어를 입력할 수 있습니다.
기본적으로 `debug` 명령어는 대화형 터미널을 디버깅된 컨테이너에 연결하고 마치 대상 컨테이너 환경에서 실행 중인 것처럼 쉘을 실행하므로, 직접 연결된 것처럼 대상 컨테이너의 파일 시스템을 볼 수 있습니다(`proc` 파일 시스템을 거칠 필요가 없음). `--run-as-target-shell`을 사용하여 이 동작을 변경할 수 있습니다(기본값은 true). 예를 들어, 이 호출은 더 전통적인 방식으로 디버그 컨테이너에 연결합니다: `slim debug --run-as-target-shell=false mycontainer`
또한 대화형 `prompt` 모드(`slim`을 명령줄 파라미터 없이 실행할 때)를 사용하는 경우 `--target`, `--session` 등 여러 플래그에 대한 자동 완성 동작을 얻을 수 있습니다.
이미지를 디버깅할 때마다 `slim`에는 이를 나타내는 세션이 생성됩니다. 기존 활성 디버그 세션에 다시 연결할 수 있으며 사용 가능한 모든 세션에서 로그를 가져올 수 있습니다.
### "어려운 방법"으로 디버깅하기 (Docker 런타임)
대상 컨테이너를 디버깅하는 데 필요한 도구가 로드된 전용 디버깅 사이드카 컨테이너 이미지를 만들 수 있습니다. 이를 통해 프로덕션 컨테이너 이미지를 작게 유지할 수 있습니다. 디버깅 사이드카 컨테이너는 실행 중인 대상 컨테이너에 부착됩니다.
`node\_app\_alpine`이라는 이름의 실행 중인 컨테이너가 있다고 가정할 때 다음과 같은 명령어로 디버깅 사이드카를 부착할 수 있습니다: `docker run --rm -it --pid=container:node\_app\_alpine --net=container:node\_app\_alpine --cap-add sys\_admin alpine sh`. 이 예시에서 디버깅 사이드카는 일반적인 alpine 이미지입니다. 이것이 바로 `node\_alpine` 앱 샘플(`examples` 리포지의 `node\_alpine` 디렉토리에 위치)과 `run\_debug\_sidecar.command` 도우미 스크립트에서 일어나는 일입니다.
사이드카에서 `ps` 명령어를 실행하면 대상 컨테이너의 애플리케이션이 표시됩니다:
```
# ps
PID USER TIME COMMAND
1 root 0:00 node /opt/my/service/server.js
13 root 0:00 sh
38 root 0:00 ps
```
`/proc//root`를 통해 대상 컨테이너 파일 시스템에 액세스할 수 있습니다:
```
# ls -lh /proc/1/root/opt/my/service
total 8
drwxr-xr-x 3 root root 4.0K Sep 2 15:51 node\_modules
-rwxr-xr-x 1 root root 415 Sep 8 00:52 server.js
```
유용한 디버깅 명령어 중에는 `cat /proc//cmdline`, `ls -l /proc//cwd`, `cat /proc/1/environ`, `cat /proc//limits`, `cat /proc//status`, `ls -l /proc//fd` 등이 있습니다.
## 명령줄 도구 최소화하기
Dockerfile의 기본 CMD 지침으로 충분하지 않은 경우 Slim에서 `build` 명령어를 실행할 때 명령줄 파라미터를 지정해야 합니다. 이는 `--cmd` 옵션을 사용하여 수행할 수 있습니다.
기 기타 유용한 명령줄 파라미터:
- `--show-clogs` - 컨테이너의 출력을 보고 싶을 때 사용하세요.
- `--mount` - Slim이 이미지를 검사할 때 볼륨을 마운트하는 데 사용하세요.
- `--entrypoint` - Slim이 이미지를 검사할 때 ENTRYPOINT 지침을 오버라이드하고 싶을 때 사용하세요.
`--entrypoint` 및 `--cmd` 옵션은 최종 최소화된 이미지의 `ENTRYPOINT` 및 `CMD` 지침을 오버라이드하지 않습니다.
다음은 샘플 `build` 명령어입니다:
`slim build --show-clogs=true --cmd docker-compose.yml --mount $(pwd)/data/:/data/ dslim/container-transform`
이것은 `container-transform` 도구를 최소화하는 데 사용됩니다. [`Docker Hub`](https://hub.docker.com/r/dslim/container-transform.slim/)에서 최소화된 이미지를 가져올 수 있습니다.
## 간단한 SECCOMP 예제
Seccomp 프로필을 자동 생성하고 이미지를 최소화하려면 `build` 명령어를 사용하세요. Seccomp 프로필만(기타 흥미로운 이미지 메타데이터와 함께) 자동 생성하려면 `profile` 명령어를 사용하세요.
1단계: Slim 실행
`slim build your-name/your-app`
2단계: 생성된 Seccomp 프로필 사용
`docker run --security-opt seccomp:/.images//artifacts/your-name-your-app-seccomp.json your-name/your-app`
생성된 프로필은 자유롭게 복사해서 사용하세요 :-)
생성된 Seccomp 프로필은 원본 이미지나 최소화된 이미지와 함께 사용할 수 있습니다.
## 자동 생성된 SECCOMP 프로필 사용하기
생성된 프로필은 원본 이미지나 Slim이 생성한 최소화된 이미지와 함께 사용할 수 있습니다:
`docker run -it --rm --security-opt seccomp:path\_to/my-sample-node-app-seccomp.json -p 8000:8000 my/sample-node-app.slim`
## 원본 데모 영상
[![DockerSlim demo](http://img.youtube.com/vi/uKdHnfEbc-E/0.jpg)](https://www.youtube.com/watch?v=uKdHnfEbc-E)
[YouTube 데모 영상](https://youtu.be/uKdHnfEbc-E)
## 데모 단계
데모는 Mac OS X에서 실행되지만 리눅스 버전을 빌드할 수도 있습니다. 이 단계들은 데모 영상의 단계와 다릅니다.
1. Slim 앱 바이너리 가져오기:
\* [Mac](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_mac.zip),
\* [Mac M1](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_mac\_m1.zip),
\* [Linux](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux.tar.gz),
\* [Linux ARM](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux\_arm.tar.gz),
\* [Linux ARM64](https://github.com/slimtoolkit/slim/releases/download/1.40.11/dist\_linux\_arm64.tar.gz)
압축을 풀고, 다른 위치에서 앱을 사용하려면 선택적으로 해당 디렉토리를 `PATH` 환경 변수에 추가하세요.
추출된 디렉토리에는 두 개의 바이너리가 포함되어 있습니다(이제 이전 이름을 위한 심볼릭 링크도 포함됨):
- `slim` <- 메인 Slim 애플리케이션 바이너리
- `slim-sensor` <- 실행 중인 컨테이너에서 정보를 수집하는 데 사용되는 센서 애플리케이션
- `docker-slim` <- 새로운 메인 앱 바이너리인 `slim`에 대한 심볼릭 링크 (스크립트에서 여전히 이전 이름을 사용하는 경우 유용함)
2. 샘플 앱을 사용하기 위해 `examples` 리포지토리 복제 (참고: 예제들은 별도의 리포지토리로 이동되었습니다). 자체 앱이 있는 경우 이 단계를 건너뛸 수 있습니다.
`git clone https://github.com/slimtoolkit/examples.git`
3. `examples/node\_ubuntu`에 있는 샘플 node.js 앱용 Docker 이미지 생성. 자체 앱이 있는 경우 이 단계를 건너뛸 수 있습니다.
`cd examples/node\_ubuntu`
`docker build -t my/sample-node-app .`
4. Slim 앱 실행:
`./slim build my/sample-node-app` <- Slim 앱 바이너리를 추출한 위치에서 실행 (또는 Slim 앱 바이너리가 있는 디렉토리를 포함하도록 `PATH` env var 업데이트)
Slim은 제공한 대상 이미지를 기반으로 특수 컨테이너를 생성합니다. 또한 이미지에 대해 발견한 정보를 저장하는 리소스 디렉토리(`/.images/`)를 생성합니다.
기본적으로 Slim 앱은 임시 컨테이너에 대해 http 프로브를 실행합니다. 웹 서비스 인터페이스를 노출하지 않는 명령줄 도구를 최소화하는 경우 http 프로빙을 명시적으로 비활성화해야 합니다(`--http-probe=false` 설정).
5. curl(또는 기타 도구)을 사용하여 샘플 앱 호출 (선택 사항)
`curl http://:`
대상 앱 컨테이너가 무언가를 수행하고 있는지 확인하기 위한 선택적 단계입니다. 애플리케이션에 따라 선택적인 단계입니다. 처리 중인 요청을 기반으로 새로운 애플리케이션 리소스를 동적으로 로드하는 일부 애플리케이션(예: Ruby 또는 Python)의 경우 필수적입니다.
Slim 앱이 대상 컨테이너를 시작할 때 매핑된 포트가 콘솔에 출력됩니다. `docker ps` 또는 `docker port` 명령어 중 하나를 통해 포트 번호를 얻을 수도 있습니다. 현재 버전의 DockerSlim은 노출된 네트워크 포트를 매핑하는 것을 허용하지 않습니다(`docker run … -P`처럼 작동함).
6. 누르고 Slim 앱이 완료되었다고 할 때까지 기다리기
기본적으로 또는 http 프로빙이 명시적으로 활성화된 경우 Slim 앱은 http 프로브 실행이 완료된 후 실행을 계속합니다. 다른 `continue-after` 옵션을 명시적으로 선택한 경우 예상되는 단계를 따르세요. 예를 들어 `enter` `continue-after` 옵션의 경우 키보드의 `enter` 버튼을 눌러야 합니다.
http 프로빙이 활성화되어 있고(`http-probe`가 설정된 경우) `continue-after`가 `enter`로 설정된 상태에서 내장된 HTTP 프로브가 완료되기 전에 `enter` 키를 누르면, 모든 probe 명령어가 실행을 완료하기 전에 Slim 앱이 대상 컨테이너를 종료하므로 프로브가 EOF 오류를 발생시킬 수 있습니다. 프로브가 완료되는 것이 정말로 중요한 경우가 아니라면 무시해도 괜찮습니다.
7. Slim이 완료되면 새로운 최소화된 이미지가 있는지 확인
`docker images`
이미지 목록에서 `my/sample-node-app.slim`을 볼 수 있어야 합니다. 현재 생성된 모든 이미지의 이름 끝에는 `.slim`이 붙습니다.
8. 최소화된 이미지 사용
`docker run -it --rm --name="slim\_node\_app" -p 8000:8000 my/sample-node-app.slim`
## FAQ
### 프로덕션 환경에서 사용해도 안전한가요?
네! 어떤 경우든 Docker 이미지는 테스트해야 합니다.
### Go 언어를 모르는데 어떻게 기여할 수 있나요?
언어 사양과 많은 책을 읽을 필요는 없습니다 :-) [Tour of Go](https://tour.golang.org/welcome/1)를 살펴보고 선택적으로 [50 Shades of Go](https://golang50shades.com/)를 읽어보면 기여할 준비가 된 것입니다!
### Slim에 가장 적합한 애플리케이션은 무엇인가요?
SlimToolkit은 모든 컨테이너화된 애플리케이션에서 작동하지만, Slim은 HTTP API가 있는 애플리케이션의 앱 상호 작용을 자동화합니다. 앱에 HTTP API가 없어도 Slim을 사용할 수 있습니다. Slim이 애플리케이션 동작을 관찰할 수 있도록 애플리케이션과 수동으로 상호 작용해야 합니다.
### Docker화된 명령줄 도구와 함께 Slim을 사용할 수 있나요?
네. `--cmd`, `--entrypoint`, `--mount` 옵션은 이미지 최소화에 도움이 됩니다. `container-transform` 도구가 좋은 예입니다.
참고:
Slim 이미지를 생성할 때 Slim이 생성하는 아티팩트를 탐색할 수 있습니다. `/.images//artifacts`에서 찾을 수 있습니다. 아티팩트 중 하나는 원본 이미지용으로 "역공학된" Dockerfile입니다. 이름은 `Dockerfile.reversed`가 됩니다.
최소화된 이미지를 생성하지 않고 Dockerfile만 "역공학"하려면 `info` 명령어를 사용할 수 있습니다.
### Docker 이미지에서 USER 명령을 사용하는 경우는 어떻게 하나요?
현재 버전의 Slim은 기본값이 아닌 사용자에 대한 지원을 포함하고 있습니다([`examples`](https://github.com/slimtoolkit/examples) 리포지의 `3rdparty` 디렉토리에 있는 ElasticSearch 예시 포함 비기본 사용자 예시들을 살펴보세요). 작동하지 않는 부분이 있으면 티켓을 열어주세요.
모든 것이 그대로 작동해야 하지만, 현재 동작이 예상대로 작동하지 않는 특수한 경우를 위해 다양한 `build` 명령어 파라미터(`--run-target-as-user`, `--keep-perms`, `--path-perms`, `--path-perms-file` 및 `--include-\*` 파라미터)를 사용하여 Slim의 동작을 조정할 수 있습니다.
`--run-target-as-user` 파라미터는 기본적으로 활성화되어 있으며 임시 컨테이너의 애플리케이션이 컨테이너의 Dockerfile에 있는 USER 지침의 신원을 사용하여 시작되는지 여부를 제어합니다.
`--keep-perms` 파라미터도 기본적으로 활성화되어 있습니다. 최적화된 컨테이너 이미지로 복사된 파일 및 디렉토리의 권한과 소유권 정보를 유지하도록 Slim에 지시합니다.
`--path-perms` 및 `--path-perms-file` 파라미터는 `--include-path` 및 `--include-path-file` 파라미터와 유사합니다. 대상 파일 및 디렉토리의 권한과 사용자/그룹 정보를 오버라이드하는 데 사용됩니다. 대상 파일/디렉토리가 최적화된 컨테이너 이미지에 포함될 것으로 예상된다는 점에 유의하세요. 대상 파일/디렉토리가 최적화된 이미지에 포함될지 확실하지 않은 경우 `--include-\*` 파라미터 중 하나(예: `--include-path-file`)를 사용하여 해당 아티팩트가 포함되도록 명시적으로 요구해야 합니다. `--include-\*` 파라미터에서도 권한과 소유권 정보를 지정할 수 있습니다(따라서 권한을 설정하기 위해 `--path-\*` 파라미터를 가질 필요가 없음).
`--path-\*` 및 `--include-\*` 파라미터는 권한/소유권 정보를 전달하기 위해 동일한 형식을 사용합니다: `TARGET\_PATH\_OR\_NAME:PERMS\_IN\_OCTAL\_FORMAT#USER\_ID#GROUP\_ID`.
사용자 및 그룹 ID를 변경하고 싶지 않다면 지정할 필요가 없습니다.
다음은 이러한 파라미터를 사용하여 표준 `nginx` 이미지를 최소화하고 추가 아티팩트를 추가하며 권한을 변경하는 예시입니다: `slim build --include-path='/opt:770#104#107' --include-path='/bin/uname:710' --path-perms='/tmp:700' nginx`.
최적화된 컨테이너 이미지에서 볼 수 있는 내용은 다음과 같습니다:
```
drwx------ 0 0 0 0 Feb 28 22:15 tmp/
-rwx--x--- 0 0 0 31240 Mar 14 2015 bin/uname
drwxrwx--- 0 104 107 0 Feb 28 22:13 opt/
```
`uname` 바이너리는 nginx에서 사용되지 않으므로 `--include-path` 파라미터를 사용하여 최적화된 이미지에 유지하면서 권한을 `710`으로 변경합니다.
`/tmp` 디렉토리는 자체적으로 최적화된 이미지에 포함되므로 `--path-perms` 파라미터를 사용하여 권한을 `700`으로 변경합니다.
디렉토리에서 권한/사용자/그룹을 설정할 때 설정은 해당 디렉토리에만 적용되고 내부의 아티팩트에는 적용되지 않습니다. 향후 버전에서는 대상 디렉토리 내부의 모든 것에도 동일한 설정을 적용할 수 있게 될 것입니다.
또한 현재는 숫자 사용자 및 그룹 ID를 사용해야 한다는 점에 유의하세요. 향후 버전에서는 사용자 및 그룹 이름도 사용할 수 있게 될 것입니다.
### 최소화된 이미지에서 Nginx가 실패합니다
`nginx: [emerg] mkdir() "/var/lib/nginx/body" failed`가 표시되면 nginx 설정이 비정상적인 임시 디렉토리를 사용하고 있음을 의미합니다. 임시 폴더의 기본 디렉토리가 존재하지 않으면 Nginx가 실패합니다(누락된 중간 디렉토리를 생성하지 않음). 일반적으로 `/var/lib/nginx`이지만 다른 것을 가리키는 사용자 지정 설정이 있는 경우 Slim 앱을 실행할 때 추가 플래그로 `--include-path` 플래그를 추가해야 합니다.
### Slim이 '읽기 권한 없음' 오류와 함께 실패합니다
내보낸 아티팩트가 tar 파일에 저장되고 마스터 앱이 더 이상 파일에 직접 액세스할 필요가 없기 때문에 이 문제는 더 이상 발생하지 않아야 합니다.
구버전의 Slim을 실행하는 경우 루트 쉘에서 Slim을 실행하여 이 문제를 우회할 수 있습니다. 이렇게 하면 내보낸 모든 파일에 액세스할 수 있습니다.
Slim은 권한을 유지하려고 시도하면서 관련 이미지 아티팩트를 복사합니다. 권한이 너무 제한적인 경우 새로운 minified 이미지를 빌드할 때 마스터 앱이 이러한 파일에 액세스할 수 있는 충분한 권한이 없을 수 있습니다.
## 빌드 프로세스
#### 빌드 옵션
가장 적합한 빌드 옵션을 선택하세요.
##### 컨테이너화됨
프로젝트 디렉토리에서 리눅스의 경우 `make build\_in\_docker`, Mac의 경우 `make build\_m1\_in\_docker`를 실행하거나 (`./scripts/docker-builder.run.sh` 또는 Mac에서 `./scripts/mac/docker-builder.run.command` 클릭) (Docker 컨테이너에서 Slim 빌드; 로컬에 Go를 설치하고 싶지 않고 이미 Docker가 있는 경우에 적합함).
##### 네이티브
리눅스의 경우 `make build`, Mac의 경우 `make build\_m1`을 실행하거나 (`./scripts/src.build.sh` 또는 Mac에서 `./scripts/src.build.command` 클릭) Slim을 네이티브로 빌드합니다(로컬에 Go가 설치되어 있어야 함).
참고:
Slim 앱을 빌드할 때는 최신 버전의 Go를 사용해 보세요. Slim 앱을 빌드하는 데 사용되는 현재 Go 버전은 1.21입니다.
##### Gitpod
웹 브라우저가 있는 경우 원클릭으로 사전 설정된 완전한 개발 환경을 얻을 수 있습니다:
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/slimtoolkit/slim)
##### 추가 도구
- `license-bill-of-materials` - 종속성과 그 라이선스를 추적하는 선택적 도구.
- `golint` - 코드 분석을 위한 선택적 도구. 자세한 내용은 `https://github.com/golang/lint` 참조.
`scripts` 디렉토리의 `tools.get.sh` 쉘 스크립트를 사용하여 이러한 도구를 설치할 수 있습니다.
참고:
- `src.inspect.sh` 또는 `mac.src.inspect.command` 스크립트를 실행하려면 `golint`가 있는지 확인하세요.
## 기여하기
프로젝트가 흥미롭거나 버그를 발견한 경우 [`CONTRIBUTING.md`](CONTRIBUTING.md)를 참조하여 PR을 제출하거나 이슈를 열어주세요! 문서를 포함한 비코드 기여는 매우 환영합니다! 질문이 있거나 명확하지 않은 부분이 있는 경우에도 이슈를 열어주세요.
### 핵심 개념
1. 컨테이너 메타데이터 검사 (정적 분석)
2. 컨테이너 데이터 검사 (정적 분석)
3. 실행 중인 애플리케이션 검사 (동적 분석)
4. 애플리케이션 아티팩트 그래프 구축
5. 수집된 애플리케이션 데이터를 사용하여 작은 이미지 빌드
6. 수집된 애플리케이션 데이터를 사용하여 다양한 보안 프레임워크 설정 자동 생성.
### 동적 분석 옵션
1. 컨테이너 이미지 계측(및 entrypoint/cmd 교체)하여 애플리케이션 활동 데이터 수집
2. 실행 중인 컨테이너에 대한 가시성을 제공하는 커널 수준 도구 사용 (컨테이너 계측 없이)
3. 컨테이너 가시성을 얻기 위해 대상 컨테이너에서 관련 네임스페이스 비활성화 (runC로 수행 가능)
### 보안
목표는 수집된 정보를 기반으로 Seccomp, AppArmor, (잠재적으로 SELinux) 프로필을 자동 생성하는 것입니다.
- AppArmor 프로필
- Seccomp 프로필
### 과제
일부 고급 분석 옵션에는 항상 포함되지는 않는 여러 Linux 커널 기능이 필요합니다. Docker Machine / Boot2docker에 포함된 커널이 그 좋은 예입니다.
## 기원
DockerSlim은 `Docker Global Hack Day` `#dockerhackday` 프로젝트였습니다. 당시에는 거의 작동하지 않았지만 시애틀에서 우승을 차지했고 전체 `Plumbing` 카테고리에서 2위를 차지했습니다 :-)
![DHD3](https://raw.githubusercontent.com/slimtoolkit/slim/master/assets/images/dhd/docker\_global\_hackday3\_red.png)
그 이후로 개선되었으며 핵심 사용 사례에 대해 꽤 잘 작동합니다. 하지만 더 나아질 수 있습니다. 그렇기 때문에 프로젝트에 여러분의 도움이 필요합니다! 컨테이너 내부, 컨테이너 런타임에 대해 잘 알 필요도 없고 Go에 대해 전혀 몰라도 됩니다. 다양한 방법으로 기여할 수 있습니다. 예를 들어, 이미지에 Slim을 사용하고 잘 작동했더라도 경험을 문서화하는 Github 이슈를 열어주세요 :-)
## 라이선스
Apache License v2, 자세한 내용은 [LICENSE](https://github.com/slimtoolkit/slim/blob/main/LICENSE)를 참조하세요.
## 행동 강령
이 프로젝트는 [CNCF 행동 강령](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)을 따릅니다.
---
\*\*우리는 [Cloud Native Computing Foundation](https://cncf.io/) 샌드박스 프로젝트입니다.\*\*
![](assets/images/cncf/cncf.svg)
---
[![Go Report Card](https://goreportcard.com/badge/github.com/slimtoolkit/slim)](https://goreportcard.com/report/github.com/slimtoolkit/slim)

slim

slim 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

slim

slim 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README