diff --git a/.docker/Dockerfile.devenv b/.docker/Dockerfile.devenv
deleted file mode 100644
index d456ab8872..0000000000
--- a/.docker/Dockerfile.devenv
+++ /dev/null
@@ -1,3 +0,0 @@
-FROM docker/dev-environments-ruby:stable-1
-RUN gem install bundler jekyll
-CMD ["bundle", "install"]
diff --git a/.docker/config.json b/.docker/config.json
deleted file mode 100644
index 8d100abe19..0000000000
--- a/.docker/config.json
+++ /dev/null
@@ -1,3 +0,0 @@
-{
- "dockerfile": "Dockerfile.devenv"
-}
diff --git a/.dockerignore b/.dockerignore
index ac58861bc2..6584adec5f 100644
--- a/.dockerignore
+++ b/.dockerignore
@@ -2,13 +2,12 @@
.github
.gitignore
.idea
-.jekyll-cache
-.jekyll-metadata
-.sass-cache
-tests
_releaser
-_site
CONTRIBUTING.md
Dockerfile
-docker-compose.yml
-/vendor
+compose.yml
+docker-bake.hcl
+public
+node_modules
+resources
+tmp
diff --git a/.editorconfig b/.editorconfig
deleted file mode 100644
index 029969f59e..0000000000
--- a/.editorconfig
+++ /dev/null
@@ -1,5 +0,0 @@
-root = true
-
-[*.{scss,html,md}]
-indent_style = space
-indent_size = 2
diff --git a/.env b/.env
deleted file mode 100644
index eb273265f8..0000000000
--- a/.env
+++ /dev/null
@@ -1,2 +0,0 @@
-COMPOSE_DOCKER_CLI_BUILD=1
-DOCKER_BUILDKIT=1
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 92b0d5397c..1505f74a3e 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -24,10 +24,13 @@ jobs:
name: Build
uses: docker/bake-action@v2
with:
+ files: |
+ docker-bake.hcl
targets: release
set: |
*.cache-from=type=gha,scope=build
*.cache-to=type=gha,scope=build,mode=max
+ *.args.HUGO_ENV=production
validate:
runs-on: ubuntu-20.04
@@ -35,8 +38,8 @@ jobs:
fail-fast: false
matrix:
target:
- - htmltest
- - mdl
+ - lint
+ - test
steps:
-
name: Checkout
@@ -48,56 +51,13 @@ jobs:
name: Validate
uses: docker/bake-action@v2
with:
- targets: ${{ matrix.target }}-output
+ files: |
+ docker-bake.hcl
+ targets: ${{ matrix.target }}
set: |
*.cache-to=type=gha,scope=validate-${{ matrix.target }},mode=max
*.cache-from=type=gha,scope=validate-${{ matrix.target }}
*.cache-from=type=gha,scope=build
- -
- name: Annotate
- uses: actions/github-script@v6
- with:
- script: |
- const fs = require('fs');
- const results = fs.readFileSync('lint/results', 'utf-8');
- if (results.length == 0) {
- process.exit(0);
- }
-
- // print results
- console.log(results);
- process.exitCode = 1;
-
- // construct annotations by parsing output
- switch ("${{ matrix.target }}") {
- case "htmltest":
- const re = /^- (.+)\n \* (.+) \(line (\d+)\)\n(.+)$/gm;
- while (true) {
- const result = re.exec(results);
- if (result === null) {
- break;
- }
-
- core.error(`${result[2]}\n${result[4]}`, {
- title: 'HTML test failed',
- // file: result[1],
- // startLine: result[3],
- });
- }
- break;
- case "mdl":
- const jsonResults = JSON.parse(results);
- for (const result of jsonResults) {
- const title = result.rule + (result.aliases.length > 0 ? ` (${result.aliases[0]})` : ``);
- console.log(`${result.filename}:${result.line}; ${title} - ${result.description}`);
- core.error(result.description, {
- title: title,
- file: result.filename,
- startLine: result.line,
- });
- }
- break;
- }
# build-releaser job will just build _releaser app used for Netlify and
# AWS deployment in publish workflow. it's just to be sure it builds correctly.
@@ -114,6 +74,8 @@ jobs:
name: Build
uses: docker/bake-action@v2
with:
+ files: |
+ docker-bake.hcl
targets: releaser-build
set: |
*.cache-from=type=gha,scope=releaser
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
index c8f9526d32..bca81e696e 100644
--- a/.github/workflows/deploy.yml
+++ b/.github/workflows/deploy.yml
@@ -21,9 +21,10 @@ jobs:
-
name: Prepare
run: |
- JEKYLL_ENV=development
+ HUGO_ENV=development
DOCS_AWS_REGION=us-east-1
if [ "${{ github.ref }}" = "refs/heads/main" ]; then
+ HUGO_ENV=staging
DOCS_URL="https://docs-stage.docker.com"
DOCS_AWS_IAM_ROLE="arn:aws:iam::710015040892:role/stage-docs-docs.docker.com-20220818202135984800000001"
DOCS_S3_BUCKET="stage-docs-docs.docker.com"
@@ -32,7 +33,7 @@ jobs:
DOCS_LAMBDA_FUNCTION_REDIRECTS="DockerDocsRedirectFunction-stage"
DOCS_SLACK_MSG="Successfully deployed docs-stage from main branch. $DOCS_URL"
elif [ "${{ github.ref }}" = "refs/heads/published" ]; then
- JEKYLL_ENV=production
+ HUGO_ENV=production
DOCS_URL="https://docs.docker.com"
DOCS_AWS_IAM_ROLE="arn:aws:iam::710015040892:role/prod-docs-docs.docker.com-20220818202218674300000001"
DOCS_S3_BUCKET="prod-docs-docs.docker.com"
@@ -41,6 +42,7 @@ jobs:
DOCS_LAMBDA_FUNCTION_REDIRECTS="DockerDocsRedirectFunction-prod"
DOCS_SLACK_MSG="Successfully deployed docs from published branch. $DOCS_URL"
elif [ "${{ github.ref }}" = "refs/heads/lab" ]; then
+ HUGO_ENV=lab
DOCS_URL="https://docs-labs.docker.com"
DOCS_AWS_IAM_ROLE="arn:aws:iam::710015040892:role/labs-docs-docs.docker.com-20220818202218402500000001"
DOCS_S3_BUCKET="labs-docs-docs.docker.com"
@@ -56,7 +58,7 @@ jobs:
SEND_SLACK_MSG="false"
fi
echo "BRANCH_NAME=${GITHUB_REF#refs/heads/}" >> $GITHUB_ENV
- echo "JEKYLL_ENV=$JEKYLL_ENV" >> $GITHUB_ENV
+ echo "HUGO_ENV=$HUGO_ENV" >> $GITHUB_ENV
echo "DOCS_URL=$DOCS_URL" >> $GITHUB_ENV
echo "DOCS_AWS_REGION=$DOCS_AWS_REGION" >> $GITHUB_ENV
echo "DOCS_AWS_IAM_ROLE=$DOCS_AWS_IAM_ROLE" >> $GITHUB_ENV
@@ -78,6 +80,8 @@ jobs:
name: Build website
uses: docker/bake-action@v2
with:
+ files: |
+ docker-bake.hcl
targets: release
set: |
*.cache-from=type=gha,scope=deploy-${{ env.BRANCH_NAME }}
@@ -93,12 +97,14 @@ jobs:
name: Upload files to S3 bucket
if: ${{ env.DOCS_S3_BUCKET != '' }}
run: |
- aws --region ${{ env.DOCS_AWS_REGION }} s3 sync --acl public-read _site s3://${{ env.DOCS_S3_BUCKET }}/ --delete
+ aws --region ${{ env.DOCS_AWS_REGION }} s3 sync --acl public-read public s3://${{ env.DOCS_S3_BUCKET }}/ --delete
-
name: Update S3 config
if: ${{ env.DOCS_S3_BUCKET != '' && env.DOCS_S3_CONFIG != '' }}
uses: docker/bake-action@v2
with:
+ files: |
+ docker-bake.hcl
targets: aws-s3-update-config
set: |
*.cache-from=type=gha,scope=releaser
@@ -111,6 +117,8 @@ jobs:
if: ${{ env.DOCS_CLOUDFRONT_ID != '' }}
uses: docker/bake-action@v2
with:
+ files: |
+ docker-bake.hcl
targets: aws-cloudfront-update
env:
AWS_REGION: us-east-1 # cloudfront and lambda edge functions are only available in us-east-1 region
diff --git a/.github/workflows/validate-upstream.yml b/.github/workflows/validate-upstream.yml
index 19f70edfc0..683b6046a2 100644
--- a/.github/workflows/validate-upstream.yml
+++ b/.github/workflows/validate-upstream.yml
@@ -1,5 +1,5 @@
# reusable workflow to validate docs from upstream repository for which pages are remotely fetched
-# - repo: repository to handle from fetch-remote in _config.yml (e.g., https://github.com/docker/buildx)
+# - repo: upstream repository (e.g., https://github.com/docker/buildx)
# - data-files-id: id of the artifact (using actions/upload-artifact) containing the YAML data files to validate (optional)
# - data-files-folder: folder in _data containing the files to download and copy to (e.g., buildx)
name: validate-upstream
@@ -7,9 +7,6 @@ name: validate-upstream
on:
workflow_call:
inputs:
- repo:
- required: true
- type: string
data-files-id:
required: false
type: string
@@ -29,57 +26,16 @@ jobs:
uses: actions/checkout@v3
with:
repository: docker/docs
- -
- name: Install js-yaml
- run: npm install js-yaml
- -
- name: Set correct ref to fetch remote resources
- uses: actions/github-script@v6
- with:
- script: |
- const fs = require('fs');
- const yaml = require('js-yaml');
-
- const configFile = '_config.yml'
- const config = yaml.load(fs.readFileSync(configFile, 'utf8'));
- for (const remote of config['fetch-remote']) {
- if (remote['repo'] != '${{ inputs.repo }}') {
- continue;
- }
- if ("${{ github.event_name }}" == "pull_request") {
- remote['repo'] = "${{ github.event.pull_request.head.repo.html_url }}";
- remote['ref'] = "${{ github.event.pull_request.head.ref }}"
- } else {
- remote['ref'] = "${{ github.ref_name }}";
- }
- }
-
- try {
- fs.writeFileSync(configFile, yaml.dump(config), 'utf8')
- } catch (err) {
- console.error(err.message)
- process.exit(1)
- }
- -
- name: Prepare
- run: |
- # print docs jekyll config updated in previous step
- yq _config.yml
- # cleanup js-yaml module and data files
- rm -rf ./node_modules
- if [[ -n "${{ inputs.data-files-folder }}" ]] && [[ -d "./_data/${{ inputs.data-files-folder }}" ]]; then
- rm -rf ./_data/${{ inputs.data-files-folder }}/*
- fi
-
name: Download data files
uses: actions/download-artifact@v3
if: ${{ inputs.data-files-id != '' && inputs.data-files-folder != '' }}
with:
name: ${{ inputs.data-files-id }}
- path: /tmp/_data/${{ inputs.data-files-folder }}
+ path: /tmp/data/${{ inputs.data-files-folder }}
-
- # Copy data files from /tmp/_data/${{ inputs.data-files-folder }} to
- # _data/${{ inputs.data-files-folder }}. If data-files-placeholder-folder
+ # Copy data files from /tmp/data/${{ inputs.data-files-folder }} to
+ # data/${{ inputs.data-files-folder }}. If data-files-placeholder-folder
# is set, then check if a placeholder file exists for each data file in
# that folder. If not, then creates a placeholder file with the same
# name as the data file, but with a .md extension.
@@ -90,19 +46,19 @@ jobs:
script: |
const fs = require('fs');
const path = require('path');
- const dataFilesPlaceholderFolder = `${{ inputs.data-files-placeholder-folder }}`;
- const globber = await glob.create(`/tmp/_data/${{ inputs.data-files-folder }}/*.yaml`);
+ const dataFilesPlaceholderFolder = `content/${{ inputs.data-files-placeholder-folder }}`;
+ const globber = await glob.create(`/tmp/data/${{ inputs.data-files-folder }}/*.yaml`);
for await (const yamlSrcPath of globber.globGenerator()) {
const yamlSrcFilename = path.basename(yamlSrcPath);
- const yamlDestPath = path.join('_data', `${{ inputs.data-files-folder }}`, yamlSrcFilename);
+ const yamlDestPath = path.join('data', `${{ inputs.data-files-folder }}`, yamlSrcFilename);
const placeholderPath = path.join(dataFilesPlaceholderFolder, yamlSrcFilename.replace(/^docker_/, '').replace(/\.yaml$/, '.md'));
if (dataFilesPlaceholderFolder !== '' && !fs.existsSync(placeholderPath)) {
const placeholderContent = `---
datafolder: ${{ inputs.data-files-folder }}
datafile: ${yamlSrcFilename.replace(/\.[^/.]+$/, '')}
title: ${yamlSrcFilename.replace(/\.[^/.]+$/, "").replaceAll('_', ' ')}
- ---
- {% include cli.md datafolder=page.datafolder datafile=page.datafile %}`;
+ layout: cli
+ ---`;
await core.group(`creating ${placeholderPath}`, async () => {
core.info(placeholderContent);
});
@@ -118,7 +74,11 @@ jobs:
name: Validate
uses: docker/bake-action@v2
with:
+ files: |
+ docker-bake.hcl
targets: validate
set: |
+ *.args.REPO="github.com/${{ github.repository }}"
+ *.args.HUGO_MODULE_REPLACEMENTS="github.com/${{ github.repository }} -> github.com/${{ github.repository}} ${{ github.ref }}"
*.cache-from=type=gha,scope=docs-upstream
*.cache-to=type=gha,scope=docs-upstream,mode=max
diff --git a/.gitignore b/.gitignore
index 50b0001ac6..09f2c1fb38 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,13 +1,9 @@
**/.DS_Store
**/desktop.ini
-.bundle/**
-.jekyll-cache
-.jekyll-metadata
-_site/**
-.sass-cache/**
.vscode
-CNAME
-_kbase/**
-/vendor
-/lint
-tmp/.htmltest/**
+node_modules
+hugo_stats.json
+.hugo_build.lock
+resources
+public
+tmp
diff --git a/.htmltest.yml b/.htmltest.yml
index 490ce1800d..2af58c68c0 100644
--- a/.htmltest.yml
+++ b/.htmltest.yml
@@ -1,4 +1,4 @@
-DirectoryPath: "_site"
+DirectoryPath: "public"
EnforceHTTPS: false
CheckDoctype: false
CheckExternal: false
diff --git a/.markdownlint.rb b/.markdownlint.rb
deleted file mode 100644
index 35dd0922e4..0000000000
--- a/.markdownlint.rb
+++ /dev/null
@@ -1,21 +0,0 @@
-# https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
-#
-# When updating rules in this file, ensure the corresponding rule list in
-# .markdownlint.json is also updated.
-
-# style
-rule 'header-style'
-rule 'hr-style'
-
-# whitespace rules
-rule 'no-missing-space-atx'
-rule 'no-multiple-space-atx'
-rule 'no-missing-space-closed-atx'
-rule 'no-multiple-space-closed-atx'
-rule 'no-space-in-emphasis'
-rule 'no-space-in-code'
-rule 'no-space-in-links'
-
-# miscellaneous
-rule 'ol-prefix', :style => :ordered
-rule 'no-reversed-links'
diff --git a/.nojekyll b/.nojekyll
deleted file mode 100644
index e69de29bb2..0000000000
diff --git a/.prettierrc b/.prettierrc
new file mode 100644
index 0000000000..b4bfed3579
--- /dev/null
+++ b/.prettierrc
@@ -0,0 +1,3 @@
+{
+ "plugins": ["prettier-plugin-tailwindcss"]
+}
diff --git a/.ruby-version b/.ruby-version
deleted file mode 100644
index 49cdd668e1..0000000000
--- a/.ruby-version
+++ /dev/null
@@ -1 +0,0 @@
-2.7.6
diff --git a/404.md b/404.md
deleted file mode 100644
index f71e5400e5..0000000000
--- a/404.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: "Sorry, we can't find that page"
-permalink: /404.html
-skip_feedback: true
-notoc: true
-sitemap: false
-skip_read_time: true
----
-
-There might be a mistake in the URL or you might've clicked a link to content
-that no longer exists. If you think it's the latter, please file an issue in
-our issue tracker on GitHub.
-
-[**Click here to create a new ticket**]({{ site.repo }}/issues/new){:.newissue.button.primary-btn}
-
-[](/ "Go to the homepage")
-
-
diff --git a/Dockerfile b/Dockerfile
index a80f2f8b8f..d0dd010fc6 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,133 +1,41 @@
# syntax=docker/dockerfile:1
-# This Dockerfile builds the docs for https://docs.docker.com/
-# from the main branch of https://github.com/docker/docs
+ARG GO_VERSION=1.21
-# Use same ruby version as the one in .ruby-version
-# that is used by Netlify
-ARG RUBY_VERSION=2.7.6
-# Same as the one in Gemfile.lock
-ARG BUNDLER_VERSION=2.3.13
-
-ARG JEKYLL_ENV=development
-ARG DOCS_URL=http://localhost:4000
-ARG DOCS_ENFORCE_GIT_LOG_HISTORY=0
-
-# Base stage for building
-FROM ruby:${RUBY_VERSION}-alpine AS base
+FROM golang:${GO_VERSION}-alpine as base
WORKDIR /src
-RUN apk add --no-cache bash build-base git
+RUN apk --update add nodejs npm git
-# Gem stage will install bundler used as dependency manager
-# for our dependencies in Gemfile for Jekyll
-FROM base AS gem
-ARG BUNDLER_VERSION
-COPY Gemfile* .
-RUN gem uninstall -aIx bundler \
- && gem install bundler -v ${BUNDLER_VERSION} \
- && bundle config set force_ruby_platform true \
- && bundle install --jobs 4 --retry 3
+FROM base as node
+COPY package*.json .
+RUN npm install
-# Vendor Gemfile for Jekyll
-FROM gem AS vendored
-ARG BUNDLER_VERSION
-RUN bundle update \
- && mkdir /out \
- && cp Gemfile.lock /out
+FROM base as hugo
+ARG HUGO_VERSION=0.116.1
+ARG TARGETARCH
+WORKDIR /bin
+RUN go install github.com/gohugoio/hugo@v${HUGO_VERSION}
-# Stage used to output the vendored Gemfile.lock:
-# > make vendor
-# or
-# > docker buildx bake vendor
-FROM scratch AS vendor
-COPY --from=vendored /out /
+FROM base as build-base
+COPY --from=hugo $GOPATH/bin/hugo /bin/hugo
+COPY --from=node /src/node_modules /src/node_modules
-# Build the static HTML for the current docs.
-# After building with jekyll, fix up some links
-FROM gem AS generate
-ARG JEKYLL_ENV
+FROM build-base as build
+ARG HUGO_ENV
ARG DOCS_URL
-ARG DOCS_ENFORCE_GIT_LOG_HISTORY
-ENV TARGET=/out
-RUN --mount=type=bind,target=.,rw \
- --mount=type=cache,target=/tmp/docker-docs-clone \
- --mount=type=cache,target=/src/.jekyll-cache < /results 2>&1
- rc=$?
- if [[ $rc -eq 0 ]]; then
- echo -n > /results
- fi
-EOF
+FROM scratch as release
+COPY --from=build /out /
-FROM base as htmltest
-COPY --from=htmltest-base /results /results
-RUN < /results
- rc=$?
- if [[ $rc -eq 0 ]]; then
- echo -n > /results
- fi
-EOF
-
-FROM mdl-base as mdl
-RUN < make release
-# or
-# > docker buildx bake release
-FROM scratch AS release
-COPY --from=generate /out /
-
-# Create a runnable nginx instance with generated HTML files.
-# When the image is run, it starts Nginx and serves the docs at port 4000:
-# > make deploy
-# or
-# > docker compose up --build
-FROM nginx:alpine AS deploy
-COPY --from=release / /usr/share/nginx/html
-COPY _deploy/nginx/default.conf /etc/nginx/conf.d/default.conf
-ARG JEKYLL_ENV
-ENV JEKYLL_ENV=${JEKYLL_ENV}
-CMD echo -e "Docker docs are viewable at:\nhttp://0.0.0.0:4000 (build target: ${JEKYLL_ENV})"; exec nginx -g 'daemon off;'
-
-FROM deploy
+FROM wjdp/htmltest:v0.17.0 as test
+WORKDIR /test
+COPY --from=build /out ./public
+ADD .htmltest.yml .htmltest.yml
+RUN htmltest
diff --git a/Gemfile b/Gemfile
deleted file mode 100644
index 4a92e5ff37..0000000000
--- a/Gemfile
+++ /dev/null
@@ -1,22 +0,0 @@
-source 'https://rubygems.org'
-
-gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]
-gem 'wdm', '>= 0.1.0' if Gem.win_platform?
-
-gem 'jekyll', '4.2.2'
-group :jekyll_plugins do
- gem 'jekyll-redirect-from'
- gem 'jekyll-relative-links'
- gem 'jekyll-sitemap'
-end
-
-# FIXME: This is a workaround for a bug in rouge console lexer
-# introduced by https://github.com/rouge-ruby/rouge/pull/1779
-# more info: https://github.com/docker/docs/issues/14788
-gem 'rouge', '3.27.0'
-
-gem 'front_matter_parser', '1.0.1'
-gem 'git', '1.13.0'
-gem 'mdl', '0.11.0'
-gem 'octopress-hooks', '2.6.2'
-gem 'rake', '13.0.6'
diff --git a/Gemfile.lock b/Gemfile.lock
deleted file mode 100644
index bf0c13bde9..0000000000
--- a/Gemfile.lock
+++ /dev/null
@@ -1,107 +0,0 @@
-GEM
- remote: https://rubygems.org/
- specs:
- addressable (2.8.1)
- public_suffix (>= 2.0.2, < 6.0)
- chef-utils (18.0.161)
- concurrent-ruby
- colorator (1.1.0)
- concurrent-ruby (1.1.10)
- em-websocket (0.5.3)
- eventmachine (>= 0.12.9)
- http_parser.rb (~> 0)
- eventmachine (1.2.7)
- ffi (1.15.5)
- forwardable-extended (2.6.0)
- front_matter_parser (1.0.1)
- git (1.13.0)
- addressable (~> 2.8)
- rchardet (~> 1.8)
- http_parser.rb (0.8.0)
- i18n (1.12.0)
- concurrent-ruby (~> 1.0)
- jekyll (4.2.2)
- addressable (~> 2.4)
- colorator (~> 1.0)
- em-websocket (~> 0.5)
- i18n (~> 1.0)
- jekyll-sass-converter (~> 2.0)
- jekyll-watch (~> 2.0)
- kramdown (~> 2.3)
- kramdown-parser-gfm (~> 1.0)
- liquid (~> 4.0)
- mercenary (~> 0.4.0)
- pathutil (~> 0.9)
- rouge (~> 3.0)
- safe_yaml (~> 1.0)
- terminal-table (~> 2.0)
- jekyll-redirect-from (0.16.0)
- jekyll (>= 3.3, < 5.0)
- jekyll-relative-links (0.6.1)
- jekyll (>= 3.3, < 5.0)
- jekyll-sass-converter (2.2.0)
- sassc (> 2.0.1, < 3.0)
- jekyll-sitemap (1.4.0)
- jekyll (>= 3.7, < 5.0)
- jekyll-watch (2.2.1)
- listen (~> 3.0)
- kramdown (2.4.0)
- rexml
- kramdown-parser-gfm (1.1.0)
- kramdown (~> 2.0)
- liquid (4.0.3)
- listen (3.7.1)
- rb-fsevent (~> 0.10, >= 0.10.3)
- rb-inotify (~> 0.9, >= 0.9.10)
- mdl (0.11.0)
- kramdown (~> 2.3)
- kramdown-parser-gfm (~> 1.1)
- mixlib-cli (~> 2.1, >= 2.1.1)
- mixlib-config (>= 2.2.1, < 4)
- mixlib-shellout
- mercenary (0.4.0)
- mixlib-cli (2.1.8)
- mixlib-config (3.0.27)
- tomlrb
- mixlib-shellout (3.2.7)
- chef-utils
- octopress-hooks (2.6.2)
- jekyll (>= 2.0)
- pathutil (0.16.2)
- forwardable-extended (~> 2.6)
- public_suffix (5.0.1)
- rake (13.0.6)
- rb-fsevent (0.11.2)
- rb-inotify (0.10.1)
- ffi (~> 1.0)
- rchardet (1.8.0)
- rexml (3.2.5)
- rouge (3.27.0)
- safe_yaml (1.0.5)
- sassc (2.4.0)
- ffi (~> 1.9)
- terminal-table (2.0.0)
- unicode-display_width (~> 1.1, >= 1.1.1)
- tomlrb (2.0.3)
- unicode-display_width (1.8.0)
-
-PLATFORMS
- aarch64-linux
- arm-linux
- x86_64-linux
-
-DEPENDENCIES
- front_matter_parser (= 1.0.1)
- git (= 1.13.0)
- jekyll (= 4.2.2)
- jekyll-redirect-from
- jekyll-relative-links
- jekyll-sitemap
- mdl (= 0.11.0)
- octopress-hooks (= 2.6.2)
- rake (= 13.0.6)
- rouge (= 3.27.0)
- tzinfo-data
-
-BUNDLED WITH
- 2.3.13
diff --git a/Makefile b/Makefile
deleted file mode 100644
index e16d918117..0000000000
--- a/Makefile
+++ /dev/null
@@ -1,37 +0,0 @@
-ifneq (, $(BUILDX_BIN))
- export BUILDX_CMD = $(BUILDX_BIN)
-else ifneq (, $(shell docker buildx version))
- export BUILDX_CMD = docker buildx
-else ifneq (, $(shell which buildx))
- export BUILDX_CMD = $(which buildx)
-else
- $(error "Buildx is required: https://github.com/docker/buildx#installing")
-endif
-
-# Build website and output to _site folder
-release:
- rm -rf _site
- $(BUILDX_CMD) bake release
-
-# Vendor Gemfile.lock
-vendor:
- $(BUILDX_CMD) bake vendor
-
-# Run all validators
-validate:
- $(BUILDX_CMD) bake validate
-
-# Check for broken links
-htmlproofer:
- $(BUILDX_CMD) bake htmlproofer
-
-# Lint tool for markdown files
-mdl:
- $(BUILDX_CMD) bake mdl
-
-# Deploy website and run it through Docker compose
-# Available in your browser at http://localhost:4000
-deploy:
- docker compose up --build
-
-.PHONY: buildx-yaml release vendor htmlproofer mdl deploy
diff --git a/_config.yml b/_config.yml
deleted file mode 100644
index 9ac43730c7..0000000000
--- a/_config.yml
+++ /dev/null
@@ -1,293 +0,0 @@
-##
-# Default configuration file
-#
-# This file overrides options set in _config.yml for production / deploy
-##
-
-name: Docker Documentation
-repo: https://github.com/docker/docs
-
-markdown: kramdown
-highlighter: rouge
-incremental: true
-permalink: pretty
-safe: false
-lsi: false
-
-# https://kramdown.gettalong.org/options.html
-# https://github.com/kramdown/parser-gfm/blob/master/lib/kramdown/parser/gfm/options.rb
-kramdown:
- input: GFM
- gfm_quirks: [paragraph_end, no_auto_typographic]
- hard_wrap: false
- html_to_native: true
- syntax_highlighter: rouge
- toc_levels: 2..3
-
-# https://jekyllrb.com/docs/configuration/liquid/
-liquid:
- error_mode: strict
-
-# Exclude directories and/or files from the conversion. These exclusions are
-# relative to the site's source directory and cannot be outside the source
-# directory.
-exclude:
- - _deploy
- - _releaser
- - docker-bake.hcl
- - LICENSE
- - Makefile
- - README.md
-
-# Component versions -- address like site.docker_ce_version
-# You can't have - characters in these for non-YAML reasons.
-# When updating 'latest_engine_api_version', also update 'min_api_threshold' below.
-latest_engine_api_version: "1.43"
-docker_ce_version: "24.0.0"
-compose_v1_version: "1.29.2"
-compose_version: "v2.20.3"
-compose_file_v3: "3.8"
-compose_file_v2: "2.4"
-machine_version: "0.16.0"
-distribution_version: "2.7"
-compose_switch_version: "1.0.4"
-buildkit_version: "0.11.6"
-
-# Strings for use in doc examples, e.g. runtime versions.
-example_go_version: "1.20"
-example_golangci_lint_version: "v1.52"
-
-# Options for displaying minimum API version requirements in the reference pages.
-#
-# The reference pages show badges for commands and options (flags) that require
-# a minimum API version. While this information can be useful if an option was
-# added in a recent version of the Docker Engine (and API), these badges are no
-# longer relevant to most users if the minimum required version is quite "old".
-#
-# We assume users reading these pages to be on the current version, or at most
-# on the version before that (which is already "unsupported"). Users running
-# older versions have bigger problems on their hand, so we're not accounting for
-# those.
-#
-# So, to reduce unnecessary clutter on the page, we only show the minimum required
-# API version if it requires a relatively recent version of the Engine.
-#
-# The "min_api_threshold" option specifies the minimum required API version for
-# which we show a badge (currently: API v1.40, or "Docker 19.03").
-min_api_threshold: 1.40
-
-# Enable search autocompletion (requires metadata.json to be generated)
-local_search: true
-
-# List of plugins to enable for local development builds. Mostly the same as
-# for production.
-plugins:
- - jekyll-redirect-from
- - jekyll-relative-links
- - jekyll-sitemap
-
-# Assets
-#
-# We specify the directory for Jekyll so we can use @imports.
-#
-# For local development, we build css with the "expanded" format to produce
-# human-readable output for easier debugging.
-sass:
- sass_dir: _scss
- style: expanded
-
-# Setting options here prevents having to repeat the same option in front-matter
-# on every page.
-# https://jekyllrb.com/docs/configuration/front-matter-defaults/
-defaults:
- - scope:
- path: ""
- type: "pages"
- values:
- layout: docs
- toc_min: 2
- toc_max: 4
-
- # Exclude from sitemap
- - scope:
- path: "desktop/enterprise"
- values:
- sitemap: false
- - scope:
- path: "assets/**"
- values:
- sitemap: false
- - scope:
- path: "**/nav.html"
- values:
- sitemap: false
- - scope:
- path: "google*.html"
- values:
- sitemap: false
- - scope:
- path: "**/*.pdf"
- values:
- sitemap: false
-
- # Set the correct edit-URL for some local and remote resources. We usually don't create a direct
- # edit link for these, and instead point to the directory that contains the file.
- - scope:
- path: engine/reference
- values:
- # FIXME: This edit url is as "best-effort" and doesn't match anything in docker/cli repo for plugins for example. It should be generated autmatically.
- edit_url: "https://github.com/docker/cli/tree/master/docs/reference"
- - scope:
- path: engine/reference/commandline
- values:
- edit_url: "https://github.com/docker/cli/tree/master/docs/reference/commandline"
- skip_read_time: true
- - scope:
- path: glossary.md
- values:
- edit_url: "https://github.com/docker/docs/blob/master/_data/glossary.yaml"
-
-# Fetch upstream resources (reference documentation) used by _plugins/fetch_remote.rb
-# - repo is the GitHub repository to fetch from
-# - default_branch used to generate edit_url link
-# - ref the Git reference
-# - paths is a list to the resources within the remote repository
-# - dest is the destination path within the working tree
-# - src is a list of glob source paths within the remote repository
-fetch-remote:
- - repo: "https://github.com/docker/cli"
- default_branch: "master"
- ref: "24.0"
- paths:
- - dest: "engine/extend"
- src:
- - "docs/extend/**"
- - dest: "engine"
- src:
- - "docs/deprecated.md"
- - dest: "engine/reference"
- src:
- - "docs/reference/run.md"
- - dest: "engine/reference/commandline"
- src:
- - "docs/reference/commandline/cli.md"
- - "docs/reference/commandline/dockerd.md"
-
- - repo: "https://github.com/docker/docker"
- default_branch: "master"
- ref: "24.0"
- paths:
- - dest: "engine/api"
- src:
- - "docs/api/**"
-
- - repo: "https://github.com/docker/compose-cli"
- default_branch: "main"
- ref: "main"
- paths:
- - dest: "cloud"
- src:
- - "docs/*.md"
- - "!docs/README.md" # readme to make things nice in the compose-cli repo, but meaningless here
- - "!docs/architecture.md" # Compose-CLI architecture, unrelated to cloud integration
-
- - repo: "https://github.com/distribution/distribution"
- default_branch: "main"
- ref: "main"
- paths:
- - dest: "registry/spec"
- src:
- - "docs/spec/**"
- - "!docs/spec/api.md.tmpl"
- - dest: "registry"
- src:
- - "docs/configuration.md"
-
- - repo: "https://github.com/moby/buildkit"
- default_branch: "master"
- ref: "master"
- paths:
- - dest: "engine/reference/builder.md"
- src:
- - "frontend/dockerfile/docs/reference.md"
- - dest: "build/buildkit/toml-configuration.md"
- src:
- - "docs/buildkitd.toml.md"
- - dest: "build/attestations/slsa-definitions.md"
- src:
- - "docs/attestations/slsa-definitions.md"
- - dest: "build/attestations/attestation-storage.md"
- src:
- - "docs/attestations/attestation-storage.md"
-
- - repo: "https://github.com/compose-spec/compose-spec"
- default_branch: "master"
- ref: "master"
- paths:
- - dest: "compose/compose-file/01-status.md"
- src:
- - "01-status.md"
- - dest: "compose/compose-file/02-model.md"
- src:
- - "02-model.md"
- - dest: "compose/compose-file/03-compose-file.md"
- src:
- - "03-compose-file.md"
- - dest: "compose/compose-file/04-version-and-name.md"
- src:
- - "04-version-and-name.md"
- - dest: "compose/compose-file/05-services.md"
- src:
- - "05-services.md"
- - dest: "compose/compose-file/06-networks.md"
- src:
- - "06-networks.md"
- - dest: "compose/compose-file/07-volumes.md"
- src:
- - "07-volumes.md"
- - dest: "compose/compose-file/08-configs.md"
- src:
- - "08-configs.md"
- - dest: "compose/compose-file/09-secrets.md"
- src:
- - "09-secrets.md"
- - dest: "compose/compose-file/10-fragments.md"
- src:
- - "10-fragments.md"
- - dest: "compose/compose-file/11-extension.md"
- src:
- - "11-extension.md"
- - dest: "compose/compose-file/12-interpolation.md"
- src:
- - "12-interpolation.md"
- - dest: "compose/compose-file/13-merge.md"
- src:
- - "13-merge.md"
- - dest: "compose/compose-file/14-include.md"
- src:
- - "14-include.md"
- - dest: "compose/compose-file/15-profiles.md"
- src:
- - "15-profiles.md"
- - dest: "compose/compose-file/build.md"
- src:
- - "build.md"
- - dest: "compose/compose-file/deploy.md"
- src:
- - "deploy.md"
-
- - repo: "https://github.com/docker/buildx"
- default_branch: "master"
- ref: "v0.11"
- paths:
- - dest: "build/bake/reference.md"
- src:
- - "docs/bake-reference.md"
-
- - repo: "https://github.com/docker/scout-cli"
- default_branch: "main"
- ref: "v0.20.0"
- paths:
- - dest: "_data/scout-cli"
- src:
- - "docs/*.yaml"
diff --git a/_config_production.yml b/_config_production.yml
deleted file mode 100644
index f509de0935..0000000000
--- a/_config_production.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-##
-# This file overrides options set in _config.yml for production / deploy
-##
-
-# Google Analytics, etc.
-google_analytics: GTM-WL2QLG5
-onetrust_id: 8e0ebfd9-035d-4ec2-9b2f-a2de9c09f906
-hotjar_id: 3169877
-
-# Assets
-#
-# For production/deploy, we build css with the "compressed" format, to produce
-# smaller files.
-sass:
- style: compressed
-
-collections:
- samples:
- output: true
diff --git a/_config_stage.yml b/_config_stage.yml
deleted file mode 100644
index ef93011c7a..0000000000
--- a/_config_stage.yml
+++ /dev/null
@@ -1,5 +0,0 @@
-##
-# This file overrides options set in _config.yml for staging environment (https://docs-stage.docker.com/)
-##
-
-hotjar_id: 3218181
diff --git a/_data/advisories.yaml b/_data/advisories.yaml
deleted file mode 100644
index c1ed057bb8..0000000000
--- a/_data/advisories.yaml
+++ /dev/null
@@ -1,19 +0,0 @@
-
-#TODO: work out how to add a data dir to any repo that has documentation
-# atm, repo's have a docs dir that is akin to the hugo content dir.
-
-
-# Define Advisory texts
-# can be used in page frontmatter, e.g.:
-# advisory: experimental
-
-texts:
- experimental: "The functionality described on this page is marked as Experimental, and as such, may change before it becomes generally available."
-
-
-# URL based advisories
-# any URL that begins with "/engine/" will get the "engine" advisory
-# will be over-ridden by the `advisory` frontmatter in the topic
-# [paths]
-# "/engine/" = "engine"
-# "/swarm/" = "swarm"
diff --git a/_data/staging-container/Dockerfile b/_data/staging-container/Dockerfile
deleted file mode 100644
index d82770fad1..0000000000
--- a/_data/staging-container/Dockerfile
+++ /dev/null
@@ -1,7 +0,0 @@
-FROM starefossen/github-pages:137
-
-VOLUME /usr/src/app
-
-EXPOSE 4000
-
-CMD jekyll serve -d /_site --watch -H 0.0.0.0 -P 4000
diff --git a/_deploy/nginx/default.conf b/_deploy/nginx/default.conf
deleted file mode 100644
index bf3a6290f8..0000000000
--- a/_deploy/nginx/default.conf
+++ /dev/null
@@ -1,26 +0,0 @@
-server {
- # Use relative redirects to account for situations where a front-end proxy is
- # used and the container does not know the public domain and port
- absolute_redirect off;
- listen 4000;
- error_page 403 404 /404.html;
- root /usr/share/nginx/html;
- index index.html;
-
- # Enable aio for better performance (see https://www.nginx.com/blog/thread-pools-boost-performance-9x/)
- aio threads;
-
- location ~ ^/v([\d\.]+)/(.*)$ {
- # Archive URLs: first try if the given file is still hosted, otherwise
- # redirect to the same URL in the current version of the docs.
- try_files $uri $uri/ @redirect_current;
- }
-
- location @redirect_current {
- # Do a 301 (moved permanently) redirect of archive pages we didn't find
- # to the same location in the current docs. Note that the location redirected
- # to may not (or no longer) exist, and as such could result in another 301
- # redirect, or a 404.
- rewrite ^/v([\d\.]+)/(.*)$ /$2 permanent;
- }
-}
diff --git a/_includes/admin-domains.md b/_includes/admin-domains.md
deleted file mode 100644
index 526eeaba6d..0000000000
--- a/_includes/admin-domains.md
+++ /dev/null
@@ -1,32 +0,0 @@
-{% if include.product == "admin" %}
- {% assign product_link="[Docker Admin](https://admin.docker.com)" %}
- {% if include.layer == "company" %}
- {% assign domain_navigation="Select your company in the left navigation drop-down menu, and then select **Domain management**." %}
- {% else" %}
- {% assign domain_navigation="Select your organization in the left navigation drop-down menu, and then select **Domain management**." %}
- {% endif %}
-{% else %}
- {% assign product_link="[Docker Hub](https://hub.docker.com)" %}
- {% assign domain_navigation="Navigate to the domain settings page for your organization or company.
- - Organization: Select **Organizations**, your organization, **Settings**, and then **Security**.
- - Company: Select **Organizations**, your company, and then **Settings**." %}
-{% endif %}
-
-
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ domain_navigation }}
-3. Select **Add a domain**.
-4. Continue with the on-screen instructions to get a verification code for your domain as a **TXT Record Value**.
-
- >**Note**
- >
- > Format your domains without protocol or www information, for example, `yourcompany.example`. This should include all email domains and subdomains users will use to access Docker, for example `yourcompany.example` and `us.yourcompany.example`. Public domains such as `gmail.com`, `outlook.com`, etc. aren’t permitted.
-
-5. Add your domain verification code as a new TXT record to your Domain Name System (DNS). The steps to do so may vary depending on your DNS provider.
-
- >**Note**
- >
- > Make sure that the TXT record name that you create on your DNS matches the domain you registered on Docker in Step 4. For example, if you registered the subdomain `us.yourcompany.example`, you need to create a TXT record within the same name/zone `us`. A root domain such as `yourcompany.example` needs a TXT record on the root zone, which is typically denoted with the `@` name for the record.
-
-6. Once you have waited 72 hours for the TXT record verification, you can then select **Verify** next to the domain you've added, and follow the on-screen instructions.
\ No newline at end of file
diff --git a/_includes/admin-image-access.md b/_includes/admin-image-access.md
deleted file mode 100644
index 19d4ae41bc..0000000000
--- a/_includes/admin-image-access.md
+++ /dev/null
@@ -1,40 +0,0 @@
-{% if include.product == "admin" %}
- {% assign product_link="[Docker Admin](https://admin.docker.com)" %}
- {% assign iam_navigation="Select your organization in the left navigation drop-down menu, and then select **Image Access**." %}
-{% else %}
- {% assign product_link="[Docker Hub](https://hub.docker.com)" %}
- {% assign iam_navigation="Select **Organizations**, your organization, **Settings**, and then select **Image Access**." %}
-{% endif %}
-
->Note
->
->Image Access Management is available to [Docker Business](/subscription/details/) customers only.
-
-Image Access Management gives administrators control over which types of images, such as Docker Official Images, Docker Verified Publisher Images, or community images, their developers can pull from Docker Hub.
-
-For example, a developer, who is part of an organization, building a new containerized application could accidentally use an untrusted, community image as a component of their application. This image could be malicious and pose a security risk to the company. Using Image Access Management, the organization owner can ensure that the developer can only access trusted content like Docker Official Images, Docker Verified Publisher Images, or the organization’s own images, preventing such a risk.
-
-## Prerequisites
-
-You need to [configure a registry.json to enforce sign-in](/docker-hub/configure-sign-in/). For Image Access Management to take effect, Docker Desktop users must authenticate to your organization.
-
-## Configure Image Access Management permissions
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ iam_navigation }}
-3. Enable Image Access Management to set the permissions for the following categories of images you can manage:
-- **Organization Images**: When Image Access Management is enabled, images from your organization are always allowed. These images can be public or private created by members within your organization.
-- **Docker Official Images**: A curated set of Docker repositories hosted on Hub. They provide OS repositories, best practices for Dockerfiles, drop-in solutions, and applies security updates on time.
-- **Docker Verified Publisher Images**: published by Docker partners that are part of the Verified Publisher program and are qualified to be included in the developer secure supply chain. You can set permissions to **Allowed** or **Restricted**.
-- **Community Images**: Images are always disabled when Image Access Management is enabled. These images are not trusted because various Docker Hub users contribute them and pose security risks.
-
- > **Note**
- >
- > Image Access Management is turned off by default. However, owners in your organization have access to all images regardless of the settings.
-
-4. Select the category restrictions for your images by selecting **Allowed**.
- Once the restrictions are applied, your members can view the organization permissions page in a read-only format.
-
-## Verify the restrictions
-
-The new Image Access Management policy takes effect after the developer successfully authenticates to Docker Desktop using their organization credentials. If a developer attempts to pull a disallowed image type using Docker, they receive an error message.
\ No newline at end of file
diff --git a/_includes/admin-sso-config.md b/_includes/admin-sso-config.md
deleted file mode 100644
index a504d51169..0000000000
--- a/_includes/admin-sso-config.md
+++ /dev/null
@@ -1,117 +0,0 @@
-{% if include.product == "admin" %}
- {% assign product_link="[Docker Admin](https://admin.docker.com)" %}
- {% assign invite_button = "**Invite**" %}
- {% assign remove_button = "**Remove member**" %}
- {% if include.layer == "company" %}
- {% assign sso_navigation="Select your company in the left navigation drop-down menu, and then select **SSO & SCIM**." %}
- {% assign domain_navigation="Select your company in the left navigation drop-down menu, and then select **Domain management**." %}
- {% assign member_navigation="Select your organization in the left navigation drop-down menu, and then select **Users**." %}
- {% assign remove_button = "**Remove user**" %}
- {% assign scim_link="[Set up SCIM](/admin/company/settings/scim/)" %}
- {% assign mapping_link="[Enable Group mapping](/admin/company/settings/group-mapping/)" %}
- {% assign sso_mgmt_link ="[Manage your SSO connections](/admin/company/settings/sso-management/)" %}
- {% else %}
- {% assign sso_navigation="Select your organization in the left navigation drop-down menu, and then select **SSO & SCIM.**" %}
- {% assign member_navigation="Select your organization in the left navigation drop-down menu, and then select **Members**." %}
- {% assign domain_navigation="Select your organization in the left navigation drop-down menu, and then select **Domain management**." %}
- {% assign remove_button = "**Remove member**" %}
- {% assign scim_link="[Set up SCIM](/admin/organization/security-settings/scim/)" %}
- {% assign mapping_link="[Enable Group mapping](/admin/organization/security-settings/group-mapping/)" %}
- {% assign sso_mgmt_link ="[Manage your SSO connections](/admin/organization/security-settings/sso-management/)" %}
- {% endif %}
-{% else %}
- {% assign product_link="[Docker Hub](https://hub.docker.com)" %}
- {% assign sso_navigation="Navigate to the SSO settings page for your organization or company.
- - Organization: Select **Organizations**, your organization, **Settings**, and then **Security**.
- - Company: Select **Organizations**, your company, and then **Settings**." %}
- {% assign domain_navigation="Navigate to the domain settings page for your organization or company.
- - Organization: Select **Organizations**, your organization, **Settings**, and then **Security**.
- - Company: Select **Organizations**, your company, and then **Settings**." %}
- {% assign member_navigation="Select **Organizations, your organization, and then **Members**." %}
- {% assign invite_button = "**Invite members**" %}
- {% assign remove_button = "**Remove member**" %}
- {% assign scim_link="[Set up SCIM](/docker-hub/scim/)" %}
- {% assign mapping_link="[Enable Group mapping](/docker-hub/group-mapping/)" %}
- {% assign sso_mgmt_link ="[Manage your SSO connections](/single-sign-on/manage/)" %}
-{% endif %}
-
-## Step two: Create an SSO connection
-
-> **Important**
->
-> If your IdP setup requires an Entity ID and the ACS URL, you must select the
-> **SAML** tab in the **Authentication Method** section. For example, if your
-> Azure AD Open ID Connect (OIDC) setup uses SAML configuration within Azure
-> AD, you must select **SAML**. If you are [configuring Open ID Connect with Azure AD](https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/configure-openid-settings){: target="_blank" rel="noopener" class="_"} select
-> **Azure AD** as the authentication method. Also, IdP initiated connections
-> aren't supported at this time.
-{: .important}
-
-After your domain is verified, create an SSO connection.
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ sso_navigation }}
-3. In the SSO connections table select **Create Connection**, and create a name for the connection.
-
- > **Note**
- >
- > You have to verify at least one domain before creating the connections.
-
-4. Select an authentication method, **SAML** or **Azure AD (OIDC)**.
-5. Copy the following fields and add them to your IdP:
-
- - SAML: **Entity ID**, **ACS URL**
- - Azure AD (OIDC): **Redirect URL**
-
- {: width="500px" }
-
- {: width="500px" }
-
-6. From your IdP, copy and paste the following values into the settings in the Docker console:
-
- - SAML: **SAML Sign-on URL**, **x509 Certificate**
- - Azure AD (OIDC): **Client ID**, **Client Secret**, **Azure AD Domain**
-
-7. Select the verified domains you want to apply the connection to.
-8. To provision your users, select the organization(s) and/or team(s).
-9. Review your summary and select **Create Connection**.
-
-## Step three: Test your SSO configuration
-
-After you’ve completed the SSO configuration process in Docker, you can test the configuration when you sign in to {{ product_link }} using an incognito browser. Sign in to {{ product_link }} using your domain email address. You are then redirected to your IdP's login page to authenticate.
-
-1. Authenticate through email instead of using your Docker ID, and test the login process.
-2. To authenticate through CLI, your users must have a PAT before you enforce SSO for CLI users.
-
->**Important**
->
-> SSO has Just-In-Time (JIT) Provisioning enabled by default. This means your users are auto-provisioned into a team called 'Company' within your organization on Docker Hub.
->
-> You can change this on a per-app basis. To prevent auto-provisioning users, you can create a security group in your IdP and configure the SSO app to authenticate and authorize only those users that are in the security group. Follow the instructions provided by your IdP:
-> - [Okta](https://help.okta.com/en-us/Content/Topics/Security/policies/configure-app-signon-policies.htm)
-> - [AzureAD](https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users)
-{: .important}
-
-The SSO connection is now created. You can continue to set up SCIM without enforcing SSO log-in. For more information about setting up SCIM, see {{ scim_link }}.
-
-## Optional step four: Enforce SSO
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ sso_navigation }}
-3. In the SSO connections table, select the **Action** icon and then **Enable enforcement**.
- When SSO is enforced, your users are unable to modify their email address and password, convert a user account to an organization, or set up 2FA through Docker Hub. You must enable 2FA through your IdP.
-4. Continue with the on-screen instructions and verify that you’ve completed the tasks.
-5. Select **Turn on enforcement** to complete.
-
-Your users must now sign in to Docker with SSO.
-
-> **Important**
->
-> If SSO isn't enforced, users can choose to sign in with either their Docker ID or SSO.
-{: .important}
-
-## What's next?
-
-- {{ sso_mgmt_link }}
-- {{ scim_link }}
-- {{ mapping_link }}
diff --git a/_includes/admin-sso-management.md b/_includes/admin-sso-management.md
deleted file mode 100644
index 5c5884a448..0000000000
--- a/_includes/admin-sso-management.md
+++ /dev/null
@@ -1,100 +0,0 @@
-{% if include.product == "admin" %}
- {% assign product_link="[Docker Admin](https://admin.docker.com)" %}
- {% assign invite_button = "**Invite**" %}
- {% if include.layer == "company" %}
- {% assign sso_navigation="Select your company in the left navigation drop-down menu, and then select **SSO & SCIM**." %}
- {% assign member_navigation="Select your organization in the left navigation drop-down menu, and then select **Users**." %}
- {% assign remove_button = "**Remove user**" %}
- {% assign scim_link="[Set up SCIM](/admin/company/settings/scim/)" %}
- {% assign mapping_link="[Enable Group mapping](/admin/company/settings/group-mapping/)" %}
- {% else %}
- {% assign sso_navigation="Select your organization in the left navigation drop-down menu, and then select **SSO & SCIM**." %}
- {% assign member_navigation="Select your organization in the left navigation drop-down menu, and then select **Members**." %}
- {% assign remove_button = "**Remove member**" %}
- {% assign scim_link="[Set up SCIM](/admin/organization/security-settings/scim/)" %}
- {% assign mapping_link="[Enable Group mapping](/admin/organization/security-settings/group-mapping/)" %}
- {% endif %}
-{% else %}
- {% assign product_link="[Docker Hub](https://hub.docker.com)" %}
- {% assign sso_navigation="Navigate to the SSO settings page for your organization or company.
- - Organization: Select **Organizations**, your organization, **Settings**, and then **Security**.
- - Company: Select **Organizations**, your company, and then **Settings**." %}
- {% assign member_navigation="Select **Organizations**, your organization, and then **Members**." %}
- {% assign invite_button = "**Invite members**" %}
- {% assign remove_button = "**Remove member**" %}
- {% assign scim_link="[Set up SCIM](/docker-hub/scim/)" %}
- {% assign mapping_link="[Enable Group mapping](/docker-hub/group-mapping/)" %}
-{% endif %}
-
-## Manage domains
-
-### Remove a domain from an SSO connection
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ sso_navigation }}
-3. In the SSO connections table, select the **Action** icon and then **Edit connection**.
-4. Select **Next** to navigate to the section where the connected domains are listed.
-5. In the **Domain** drop-down, select the **x** icon next to the domain that you want to remove.
-6. Select **Next** to confirm or change the connected organization(s).
-7. Select **Next** to confirm or change the default organization and team provisioning selections.
-8. Review the **Connection Summary** and select **Save**.
-
-> **Note**
->
-> If you want to re-add the domain, a new TXT record value is assigned. You must then complete the verification steps with the new TXT record value.
-
-## Manage SSO connections
-
-### Edit a connection
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ sso_navigation }}
-3. In the SSO connections table, select the **Action** icon.
-4. Select **Edit connection** to edit your connection.
-5. Follow the on-screen instructions to edit the connection.
-
-### Delete a connection
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ sso_navigation }}
-3. In the SSO connections table, select the **Action** icon.
-4. Select **Delete connection**.
-5. Follow the on-screen instructions to delete a connection.
-
-### Deleting SSO
-
-When you disable SSO, you can delete the connection to remove the configuration settings and the added domains. Once you delete this connection, it can't be undone. Users must authenticate with their Docker ID and password or create a password reset if they don't have one.
-
-## Manage users
-
-> **Important**
->
-> SSO has Just-In-Time (JIT) Provisioning enabled by default. This means your users are auto-provisioned into a team called 'Company' within your organization.
->
-> You can change this on a per-app basis. To prevent auto-provisioning users, you can create a security group in your IdP and configure the SSO app to authenticate and authorize only those users that are in the security group. Follow the instructions provided by your IdP:
-> - [Okta](https://help.okta.com/en-us/Content/Topics/Security/policies/configure-app-signon-policies.htm){: target="_blank" rel="noopener" class="_"}
-> - [AzureAD](https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users){: target="_blank" rel="noopener" class="_"}
-{: .important}
-
-### Add guest users when SSO is enabled
-
-To add a guest if they aren’t verified through your IdP:
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. Select {{ invite_button }}.
-4. Follow the on-screen instructions to invite the user.
-
-### Remove users from the SSO company
-
-To remove a user:
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. Select the action icon next to a user’s name, and then select {{ remove_button }}.
-4. Follow the on-screen instructions to remove the user.
-
-## What's next?
-
-- {{ scim_link }}
-- {{ mapping_link }}
\ No newline at end of file
diff --git a/_includes/admin-users.md b/_includes/admin-users.md
deleted file mode 100644
index 2a4096a4cb..0000000000
--- a/_includes/admin-users.md
+++ /dev/null
@@ -1,138 +0,0 @@
-
-{% if include.product == "admin" %}
- {% assign product_link="[Docker Admin](https://admin.docker.com)" %}
- {% assign invite_button = "**Invite**" %}
- {% assign export_button = "the **Action** icon and then select **Export users as CSV**" %}
- {% if include.layer == "company" %}
- {% assign member_navigation="Select your company in the left navigation drop-down menu, and then select **Users**." %}
- {% assign remove_button = "**Remove user**" %}
- {% assign update_role = "Select their organization, select the role you want to assign, and then select **Save**." %}
- {% else %}
- {% assign member_navigation="Select your organization in the left navigation drop-down menu, and then select **Members**." %}
- {% assign remove_button = "**Remove member**" %}
- {% assign update_role = "Select the role you want to assign, then select **Save**." %}
- {% endif %}
-{% else %}
- {% assign product_link="[Docker Hub](https://hub.docker.com)" %}
- {% assign member_navigation="Select **Organizations**, your organization, and then **Members**." %}
- {% assign invite_button = "**Invite members**" %}
- {% assign remove_button = "**Remove member**" %}
- {% assign export_button = "**Export members**" %}
- {% assign update_role = "Select the role you want to assign, then select **Save**." %}
-{% endif %}
-
-## Invite members
-
-Owners can invite new members to an organization via Docker ID, email address, or via a CSV file containing email addresses. If an invitee does not have a Docker account, they must create an account and verify their email address before they can accept the invitation to join the organization. When inviting members, their pending invitation occupies a seat.
-
-### Invite members via Docker ID or email address
-
-Use the following steps to invite members to your organization via Docker ID or email address. To invite a large amount of members to your organization via CSV file, see the next section.
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. Select {{ invite_button }}.
-4. Select **Emails or usernames**.
-5. Follow the on-screen instructions to invite members. Invite a maximum of 1000 members and separate multiple entries by comma, semicolon, or space.
-
- > **Note**
- >
- > When you invite members, you assign them a role. See [Roles and permissions](/docker-hub/roles-and-permissions/) for details about the access permissions for each role.
-
-Pending invitations appear in the table. The invitees receive an email with a link to Docker Hub where they can accept or decline the invitation.
-
-### Invite members via CSV file
-
-To invite multiple members to an organization via a CSV file containing email addresses:
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. Select {{ invite_button }}.
-4. Select **CSV upload**.
-5. Select **Download the template CSV file** to optionally download an example CSV file. The following is an example of the contents of a valid CSV file.
- ```
- email
- docker.user-0@example.com
- docker.user-1@example.com
- ```
- CSV file requirements:
- - The file must contain a header row with at least one heading named `email`. Additional columns are allowed and are ignored in the import.
- - The file must contain a maximum of 1000 email addresses (rows). To invite more than 1000 users, create multiple CSV files and perform all steps in this task for each file.
-6. Create a new CSV file or export a CSV file from another application.
- - To export a CSV file from another application, see the application’s documentation.
- - To create a new CSV file, open a new file in a text editor, type `email` on the first line, type the user email addresses one per line on the following lines, and then save the file with a .csv extension.
-7. Select **Browse files** and then select your CSV file, or drag and drop the CSV file into the **Select a CSV file to upload** box. You can only select one CSV file at a time.
- > **Note**
- >
- > If the amount of email addresses in your CSV file exceeds the number of available seats in your organization, you cannot continue to invite members. To invite members, you can purchase more seats, or remove some email addresses from the CSV file and re-select the new file. To purchase more seats, see [Add seats to your subscription](/subscription/add-seats/) or [Contact sales](https://www.docker.com/pricing/contact-sales/).
-8. After the CSV file has been uploaded, select **Review**.
- Valid email addresses and any email addresses that have issues appear.
- Email addresses may have the following issues:
- - **Invalid email**: The email address is not a valid address. The email address will be ignored if you send invites. You can correct the email address in the CSV file and re-import the file.
- - **Already invited**: The user has already been sent an invite email and another invite email will not be sent.
- - **Member**: The user is already a member of your organization and an invite email will not be sent.
- - **Duplicate**: The CSV file has multiple occurrences of the same email address. The user will be sent only one invite email.
-9. Follow the on-screen instructions to invite members.
-
- > **Note**
- >
- > When you invite members, you assign them a role. See [Roles and permissions](/docker-hub/roles-and-permissions/) for details about the access permissions for each role.
-
-
-Pending invitations appear in the table. The invitees receive an email with a link to Docker Hub where they can accept or decline the invitation.
-
-## Resend invitations
-
-To resend an invitation if the invite is pending or declined:
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. In the table, locate the invitee, select the **Action** icon, and then select **Resend invitation**.
-4. Select **Invite** to confirm.
-
-## Remove a member or invitee
-
-To remove a member from an organization:
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. In the table, select the **Action** icon, and then select {{ remove_button }} or **Remove invitee**.
-4. Follow the on-screen instructions to remove the member or invitee.
-
-## Update a member role
-
-Organization owners can manage [roles](/docker-hub/roles-and-permissions/) within an organization. If an organization is part of a company, the company owner can also manage that organization's roles.
-
-> **Note**
->
-> If you're the only owner of an organization, you need to assign a new owner before you can edit your role.
-
-To update a member role:
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. Find the username of the member whose role you want to edit. In the table, select the **Actions** icon.
-4. Select **Edit role**.
-5. {{ update_role }}
-
-## Export members
-
-Owners can export a CSV file containing all members.
-The CSV file may contain the following fields:
-
- * **Name**: The user's name.
- * **Username**: The user's Docker ID.
- * **Email**: The user's email address.
- * **Type**: The type of user. For example, **Invitee** for users who have not accepted the organization's invite, or **User** for users who are members of the organization.
- * **Permission**: The user's organization permissions. For example, **Member** or **Owner**.
- * **Teams**: The teams where the user is a member. A team is not listed for invitees.
- * **Date Joined**: The time and date when the user was invited to the organization.
- * **Member of Organizations**: All organizations the user is a member of within a company.
- * **Invited to Organizations**: All organizations the user is an invitee of within a company.
- * **Account Created**: The time and date when the user account was created.
-
-To export a CSV file of the members:
-
-1. Sign in to {{ product_link }}{: target="_blank" rel="noopener" class="_"}.
-2. {{ member_navigation }}
-3. Select {{ export_button }}.
diff --git a/_includes/analytics/feedback.html b/_includes/analytics/feedback.html
deleted file mode 100644
index d47659746a..0000000000
--- a/_includes/analytics/feedback.html
+++ /dev/null
@@ -1,13 +0,0 @@
-{%- if site.hotjar_id and site.hotjar_id != '' and page.skip_feedback != true -%}
-
-
-{%- endif -%}
diff --git a/_includes/analytics/google_analytics.html b/_includes/analytics/google_analytics.html
deleted file mode 100644
index 3c538dc737..0000000000
--- a/_includes/analytics/google_analytics.html
+++ /dev/null
@@ -1,7 +0,0 @@
-{% if include.GOOGLE_ID and include.GOOGLE_ID != '' %}
-
-{% else %}{% endif %}
\ No newline at end of file
diff --git a/_includes/analytics/onetrust.html b/_includes/analytics/onetrust.html
deleted file mode 100644
index 078024ff50..0000000000
--- a/_includes/analytics/onetrust.html
+++ /dev/null
@@ -1,7 +0,0 @@
-{% if include.ONETRUST_ID and include.ONETRUST_ID != '' %}
-
-
-
-{% else %}{% endif %}
diff --git a/_includes/breadcrumbs.html b/_includes/breadcrumbs.html
deleted file mode 100644
index 9d0286ee4c..0000000000
--- a/_includes/breadcrumbs.html
+++ /dev/null
@@ -1,126 +0,0 @@
-{%- comment -%}
-Yet-another hacky way to do things with Liquid
-
-This include constructs breadcrumbs for the page; breadcrumbs are based on the
-page's location in the TOC (_data/toc.yaml). To get the "parent" TOC entries
-for the current page, we:
-
- - iterate through each of the main sections / categories in the TOC (home, guides,
- manuals, reference, samples)
- - in each section, we iterate throught pages and sections. "sections" do not
- have URLs ("path") of their own, but can contain pages and sub-sections.
- Liquid doesn't allow us to "recursively" iterate through these, so we added
- code for each nested level (currently accounting for pages to be nested up to
- 4 levels deep)
- - If the item we're checking is a page (i.e., has a "path" property), and the
- "path" matches the current page, then we found our "breadcrumb path"; in this
- case we store the parent elements into variables (levelX_title, levelX_url).
- Liquid doesn't seem to like storing the whole struct into a variable (we can
- *store* it in a variable, but the "path" property ends up empty). We also have
- to "assign" inside the level-block; likely because variables assigned in the
- previous block gets out of scope.
- - Because (as mentioned) "sections" themselves currently do not have their own
- URL, we don't have a real "parent" URL, so we're using the _first_ page at
- each level as the "closest match". In some cases, a section does not contain
- pages (only subsections); in those cases, our breadcrumbs will contain "titles"
- for parent locations, but no link. (This is something we need to fix: make
- sure that each section has a landing-page, and possibly add a "path" field
- to sections (containing the landing page of the section).
-{%- endcomment -%}
-{%- for section in site.data.toc.horizontalnav -%}
- {%- for level1 in site.data.toc[section.node] -%}
- {%- if level1.path == page.url -%}
- {%- assign found = "true" -%}
- {%- assign section_title = section.title -%}
- {%- assign section_url = section.path -%}
- {%- assign level1_title = level1.title -%}
- {%- assign level1_url = level1.path -%}
- {%- break -%}
- {%- endif -%}
- {%- for level2 in level1.section -%}
- {%- if level2.path == page.url -%}
- {%- assign found = "true" -%}
- {%- assign section_title = section.title -%}
- {%- assign section_url = section.path -%}
- {%- assign level1_title = level1.sectiontitle -%}
- {%- assign level1_url = level1.section[0].path -%}
- {%- assign level2_title = level2.title -%}
- {%- assign level2_url = level2.path -%}
- {%- break -%}
- {%- endif -%}
- {%- for level3 in level2.section -%}
- {%- if level3.path == page.url -%}
- {%- assign found = "true" -%}
- {%- assign section_title = section.title -%}
- {%- assign section_url = section.path -%}
- {%- assign level1_title = level1.sectiontitle -%}
- {%- assign level1_url = level1.section[0].path -%}
- {%- assign level2_title = level2.sectiontitle -%}
- {%- assign level2_url = level2.section[0].path -%}
- {%- assign level3_title = level3.title -%}
- {%- assign level3_url = level3.path -%}
- {%- break -%}
- {%- endif -%}
- {%- for level4 in level3.section -%}
- {%- if level4.path == page.url -%}
- {%- assign found = "true" -%}
- {%- assign section_title = section.title -%}
- {%- assign section_url = section.path -%}
- {%- assign level1_title = level1.sectiontitle -%}
- {%- assign level1_url = level1.section[0].path -%}
- {%- assign level2_title = level2.sectiontitle -%}
- {%- assign level2_url = level2.section[0].path -%}
- {%- assign level3_title = level3.sectiontitle -%}
- {%- assign level3_url = level3.section[0].path -%}
- {%- assign level4_title = level4.title -%}
- {%- assign level4_url = level4.path -%}
- {%- break -%}
- {%- endif -%}
- {%- for level5 in level4.section -%}
- {%- if level5.path == page.url -%}
- {%- assign found = "true" -%}
- {%- assign section_title = section.title -%}
- {%- assign section_url = section.path -%}
- {%- assign level1_title = level1.sectiontitle -%}
- {%- assign level1_url = level1.section[0].path -%}
- {%- assign level2_title = level2.sectiontitle -%}
- {%- assign level2_url = level2.section[0].path -%}
- {%- assign level3_title = level3.sectiontitle -%}
- {%- assign level3_url = level3.section[0].path -%}
- {%- assign level4_title = level4.title -%}
- {%- assign level4_url = level4.path -%}
- {%- assign level5_title = level5.title -%}
- {%- assign level5_url = level5.path -%}
- {%- break -%}
- {%- endif -%}
- {%- endfor -%}
- {%- endfor -%}
- {%- endfor -%}
- {%- endfor -%}
- {%- endfor -%}
- {%- comment -%}
- Some section's overview page are not in the TOC. If we didn't find a matching
- page in the TOC so far, use the section itself for the breadcrumb.
- {%- endcomment -%}
- {%- if section.path == page.url -%}
- {%- assign found = "true" -%}
- {%- assign section_title = section.title -%}
- {%- assign section_url = section.path -%}
- {%- break -%}
- {%- endif -%}
-{%- endfor -%}
-{%- if found == "true" -%}
-
-
-
-{%- endif -%}
diff --git a/_includes/cli.md b/_includes/cli.md
deleted file mode 100644
index 3df6605f48..0000000000
--- a/_includes/cli.md
+++ /dev/null
@@ -1,156 +0,0 @@
-{% capture tabChar %} {% endcapture %}
-{% assign controller_data = site.data[include.datafolder][include.datafile] %}
-{% assign parentPath = page.path | prepend: "/" | remove: page.name %}
-
-
-
-{{ controller_data.short | replace_relative_links: page.path }}
-
-{% if controller_data.min_api_version %}
-{% comment %}
- To reduce unnecessary clutter on the page, we only show the minimum required
- API version if it requires a relatively recent version of the Engine, which
- is configured through the "min_api_threshold" option in _config.yml
-
- Below, we first convert the min_api_version from a string to a number, so that
- we can compare versions (see https://stackoverflow.com/a/27200972/1811501),
- then compare it, to decide whether to show the "minimum required API version".
-{% endcomment %}
-{% assign min_api_version = controller_data.min_api_version | plus: 0 %}
-{% if min_api_version >= site.min_api_threshold %}
-
-API {{ controller_data.min_api_version }}+
-The client and daemon API must both be at least
-{{ controller_data.min_api_version }}
-to use this command. Use the `docker version` command on the client to check
-your client and daemon API versions.
-
-{% endif %}
-{% endif %}
-
-{% if controller_data.deprecated %}
-
-> This command is [deprecated](/engine/deprecated/){: target="_blank" rel="noopener" class="_"}.
->
-> It may be removed in a future Docker version. For more information, see the [Docker Roadmap](https://github.com/docker/roadmap/issues/209){: target="_blank" rel="noopener" class="_"}.
-{: .warning }
-
-{% endif %}
-
-{% if controller_data.experimental %}
-
-> This command is experimental.
->
-> This command is experimental on the Docker daemon. It should not be used in
-> production environments.
-> To enable experimental features on the Docker daemon, edit the
-> [daemon.json](/engine/reference/commandline/dockerd/#daemon-configuration-file)
-> and set `experimental` to `true`.
->
-> {% include experimental.md %}
-
-{% endif %}
-
-{% if controller_data.experimentalcli %}
-
-> This command is experimental.
->
-> [Experimental features](/engine/reference/commandline/cli/#experimental-features)
-> are intended for testing and feedback as their functionality or UX may change
-> between releases without warning or can be removed entirely in a future release.
-{: .important }
-
-{% endif %}
-
-{% capture command-orchestrator %}
-{% if controller_data.swarm %}
-
-Swarm This command works with the Swarm orchestrator.
-
-{% endif %}
-{% endcapture %}{{ command-orchestrator }}
-
-
-{% if controller_data.usage %}
-
-## Usage
-
-```console
-$ {{ controller_data.usage | replace: tabChar, "" | strip }}{% if controller_data.cname %} COMMAND{% endif %}
-```
-
-{% endif %}
-{% unless controller_data.long == controller_data.short %}
-{% if controller_data.options %}
-Refer to the [options section](#options) for an overview of available [`OPTIONS`](#options) for this command.
-{% endif %}
-
-## Description
-
-{: name="extended-description"}
-
-{{ controller_data.long | replace_relative_links: page.path }}
-
-{% endunless %}
-
-{% if controller_data.examples %}
-For example uses of this command, refer to the [examples section](#examples) below.
-{% endif %}
-
-{% if controller_data.options %}
- {% if controller_data.inherited_options %}
- {% assign alloptions = controller_data.options | concat:controller_data.inherited_options %}
- {% else %}
- {% assign alloptions = controller_data.options %}
- {% endif %}
-## Options
-
-
-{% endif %}
-
-{% if controller_data.examples %}
-
-## Examples
-
-{{ controller_data.examples | replace_relative_links: page.path }}
-
-{% endif %}
diff --git a/_includes/content/moby.md b/_includes/content/moby.md
deleted file mode 100644
index 4763d51e90..0000000000
--- a/_includes/content/moby.md
+++ /dev/null
@@ -1,15 +0,0 @@
-Docker [introduced the open source Moby
-project](https://blog.docker.com/2017/04/introducing-the-moby-project/) to
-further promote collaboration, experimentation, and development of
-container-based systems in the broader community. Moby is a library of
-containerized components, a framework for assembling components into a container
-platform, and tools to build, test, and deploy artifacts. It included a
-reference assembly, which is the open base for the Docker platform.
-
-You can read about the Moby project, the open framework, components, and
-relationship of Docker to Moby at [mobyproject.org](https://mobyproject.org/).
-
-The Moby project lives [here](https://github.com/moby/moby).
-
-See [Contribute to the Moby project](https://github.com/moby/moby/blob/master/CONTRIBUTING.md)
-to learn how to help work on the codebase.
diff --git a/_includes/content/ssh/ssh-add-keys-to-agent.md b/_includes/content/ssh/ssh-add-keys-to-agent.md
deleted file mode 100644
index 5837d5906f..0000000000
--- a/_includes/content/ssh/ssh-add-keys-to-agent.md
+++ /dev/null
@@ -1,95 +0,0 @@
-
-
-
-{% capture mac-content-add %}
-1. Start the `ssh-agent` in the background using the command `eval "$(ssh-agent -s)"`. You get the agent process ID in return.
-
- ```none
- eval "$(ssh-agent -s)"
- Agent pid 59566
- ```
-
-2. On macOS Sierra 10.12.2 or newer, modify your
-`~/.ssh/config` file to automatically load keys into the `ssh-agent` and store
-passphrases in your keychain.
-
- ```none
- Host *
- AddKeysToAgent yes
- UseKeychain yes
- IdentityFile ~/.ssh/id_rsa
- ```
-
-3. Add your SSH private key to the ssh-agent, using the default macOS `ssh-add` command.
-
- ```none
- $ ssh-add -K ~/.ssh/id_rsa
- ```
-
- If you created your key with a different name or have an existing key
- with a different name, replace `id_rsa` in the command with the
- name of your private key file.
-
-{% endcapture %}
-{{ mac-content-add | markdownify }}
-
-
-
-
-
-{% capture win-content-add %}
-
-1. Start the `ssh-agent` in the background.
-
- ```none
- eval "$(ssh-agent -s)"
- Agent pid 59566
- ```
-
-2. Add your SSH private key to the ssh-agent.
-
- ```none
- $ ssh-add ~/.ssh/id_rsa
- ```
-
- If you created your key with a different name or have an existing key
- with a different name, replace `id_rsa` in the command with the
- name of your private key file.
-
-{% endcapture %}
-{{ win-content-add | markdownify }}
-
-
-
-
-
-{% capture linux-content-add %}
-
-1. Start the `ssh-agent` in the background.
-
- ```none
- eval "$(ssh-agent -s)"
- Agent pid 59566
- ```
-
-2. Add your SSH private key to the ssh-agent.
-
- ```none
- $ ssh-add ~/.ssh/id_rsa
- ```
-
- If you created your key with a different name or have an existing key
- with a different name, replace `id_rsa` in the command with the
- name of your private key file.
-
-{% endcapture %}
-{{ linux-content-add | markdownify }}
-
-
-
-{% capture mac-content-copy %}
-
-Copy the public SSH key to your clipboard.
-
-```none
-$ pbcopy < ~/.ssh/id_rsa.pub
-```
-
-If your SSH key file has a different name than the example code, modify the
-filename to match your current setup.
-
->**Tip:** If you don't have `pbcopy`, you navigate to the hidden `.ssh`
-folder, open the file in a text editor, and copy it to your clipboard.
-For example: `$ atom ~/.ssh/id_rsa.pub`
-
-{% endcapture %}
-{{ mac-content-copy | markdownify }}
-
-
-
-
-
-{% capture win-content-copy %}
-
-Copy the public SSH key to your clipboard.
-
-```none
-$ clip < ~/.ssh/id_rsa.pub
-```
-
-If your SSH key file has a different name than the example code, modify the
-filename to match your current setup.
-
->**Tip:** If `clip` doesn't work, navigate the hidden `.ssh`
-folder, open the file in a text editor, and copy it to your clipboard.
-For example: `$ notepad ~/.ssh/id_rsa.pub`
-
-{% endcapture %}
-{{ win-content-copy | markdownify }}
-
-
-
-
-
-{% capture linux-content-copy %}
-
-If you don't already have it, install `xclip`. (The example uses `apt-get` to install, but you might want to use another package installer like `yum`.)
-
-```none
-$ sudo apt-get install xclip
-```
-
-Copy the SSH key to your clipboard.
-
-```none
-$ xclip -sel clip < ~/.ssh/id_rsa.pub
-```
-
->**Tip:** If you `xclip` isn't working, navigate to hidden `.ssh` folder,
-open the file in a text editor, and copy it to your clipboard.
-For example: `$ vi ~/.ssh/id_rsa.pub`
-
-{% endcapture %}
-{{ linux-content-copy | markdownify }}
-
-
-
-{% capture mac-content-find %}
-
-1. Open a command-line terminal.
-
- ```none
- $ ls -al ~/.ssh
- ```
-
- This lists files in your `.ssh` directory.
-
-2. Check to see if you already have a SSH keys you can use.
-
- Default file names for public keys are:
-
- * id_dsa.pub
- * id_ecdsa.pub
- * id_ed25519.pub
- * id_rsa.pub
-
- Here are example results showing a public and private key pair with the default names:
-
- ```none
- drwx------ 8 me staff 272 Mar 27 14:04 .
- drwxr-xr-x+ 69 me staff 2346 Apr 7 10:03 ..
- -rw-r--r-- 1 me staff 420 Mar 27 14:04 config
- -rw------- 1 me staff 3326 Mar 27 14:01 id_rsa
- -rw-r--r-- 1 me staff 752 Mar 27 14:01 id_rsa.pub
- ```
-
- The file `id_rsa` contains the private key which resides on the local machine, and `id_rsa.pub` is the public key we can provide to a remote account.
-
-{% endcapture %}
-{{ mac-content-find | markdownify }}
-
-
-
-
-
-{% capture win-content-find %}
-
-1. Open Git Bash.
-
- ```none
- $ ls -al ~/.ssh
- ```
-
- This lists files in your `.ssh` directory.
-
-2. Check to see if you already have SSH keys you can use.
-
- Default file names for public keys are:
-
- * id_dsa.pub
- * id_ecdsa.pub
- * id_ed25519.pub
- * id_rsa.pub
-
- Here are example results showing a public and private key pair with the default names:
-
- ```none
- drwx------ 8 me staff 272 Mar 27 14:04 .
- drwxr-xr-x+ 69 me staff 2346 Apr 7 10:03 ..
- -rw-r--r-- 1 me staff 420 Mar 27 14:04 config
- -rw------- 1 me staff 3326 Mar 27 14:01 id_rsa
- -rw-r--r-- 1 me staff 752 Mar 27 14:01 id_rsa.pub
- ```
-
- The file `id_rsa` contains the private key which resides on the local machine, and `id_rsa.pub` is the public key we can provide to a remote account.
-
-{% endcapture %}
-{{ win-content-find | markdownify }}
-
-
-
-
-
-{% capture linux-content-find %}
-
-1. Open a command-line terminal.
-
- ```none
- $ ls -al ~/.ssh
- ```
-
- This lists files in your `.ssh` directory.
-
-2. Check to see if you already have a SSH keys you can use.
-
- Default file names for public keys are:
-
- * id_dsa.pub
- * id_ecdsa.pub
- * id_ed25519.pub
- * id_rsa.pub
-
- Here are example results showing a public and private key pair with the default names:
-
- ```none
- drwx------ 8 me staff 272 Mar 27 14:04 .
- drwxr-xr-x+ 69 me staff 2346 Apr 7 10:03 ..
- -rw-r--r-- 1 me staff 420 Mar 27 14:04 config
- -rw------- 1 me staff 3326 Mar 27 14:01 id_rsa
- -rw-r--r-- 1 me staff 752 Mar 27 14:01 id_rsa.pub
- ```
-
- The file `id_rsa` contains the private key which resides on the local machine, and `id_rsa.pub` is the public key we can provide to a remote account.
-
-{% endcapture %}
-{{ linux-content-find | markdownify }}
-
-
-
-{% capture mac-content-gen %}
-1. Open a command-line terminal.
-
-2. Paste the text below, substituting in your GitHub email address.
-
- ```none
- ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
- ```
-
- This creates a new SSH key, using the provided email as a label.
-
- ```none
- Generating public/private rsa key pair.
- ```
-
-3. When prompted with "Enter a file in which to save the key", press the Return key (Enter) to accept the default location.
-
- ```none
- Enter a file in which to save the key (/Users/you/.ssh/id_rsa):
- ```
-
-4. At the prompt, type a secure passphrase, and re-enter as prompted.
-
- ```none
- Enter passphrase (empty for no passphrase):
- Enter same passphrase again:
- ```
-{% endcapture %}
-{{ mac-content-gen | markdownify }}
-
-
-
-
-
-{% capture win-content-gen %}
-1. Open Git Bash.
-
-2. Paste the text below, substituting in your GitHub email address.
-
- ```none
- ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
- ```
-
- This creates a new SSH key, using the provided email as a label.
-
- ```none
- Generating public/private rsa key pair.
- ```
-
-3. When prompted with "Enter a file in which to save the key", press the Return key (Enter) to accept the default location.
-
- ```none
- Enter a file in which to save the key (c/Users/you/.ssh/id_rsa):
- ```
-
-4. At the prompt, type a secure passphrase, and re-enter as prompted.
-
- ```none
- Enter passphrase (empty for no passphrase):
- Enter same passphrase again:
- ```
-{% endcapture %}
-{{ win-content-gen | markdownify }}
-
-
-
-
-
-{% capture linux-content-gen %}
-1. Open a command-line terminal.
-
-2. Paste the text below, substituting in your GitHub email address.
-
- ```none
- ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
- ```
-
- This creates a new SSH key, using the provided email as a label.
-
- ```none
- Generating public/private rsa key pair.
- ```
-
-3. When prompted with "Enter a file in which to save the key", press the Return key (Enter) to accept the default location.
-
- ```none
- Enter a file in which to save the key (/home/you/.ssh/id_rsa):
- ```
-
-4. At the prompt, type a secure passphrase, and re-enter as prompted.
-
- ```none
- Enter passphrase (empty for no passphrase):
- Enter same passphrase again:
- ```
-{% endcapture %}
-{{ linux-content-gen | markdownify }}
-
-
-
diff --git a/_includes/content/ssh/ssh-overview.md b/_includes/content/ssh/ssh-overview.md
deleted file mode 100644
index 217cfa987d..0000000000
--- a/_includes/content/ssh/ssh-overview.md
+++ /dev/null
@@ -1,14 +0,0 @@
-[SSH](/glossary/#SSH) is a secure protocol for accessing remote machines and applications. It
-provides authentication and encrypts data communication over insecure networks.
-
-These topics describe how to find existing SSH keys or generate new ones, and
-add the public key to your Docker Hub account. GitHub has a good set of
-topics on [Connecting to GitHub with
-SSH](https://help.github.com/articles/connecting-to-github-with-ssh/), which you
-can tailor to SSH scenarios beyond GitHub, including Docker. The quick-look
-topics below are derived from that GitHub documentation.
-
-Commands for working with SSH keys are described for Mac, Windows, and Linux.
-The Windows steps suggest using [Git Bash](https://git-for-windows.github.io/) but you could also use a tool like
-[PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) or
-[Bitvise](https://www.bitvise.com/index).
diff --git a/_includes/desktop-install.md b/_includes/desktop-install.md
deleted file mode 100644
index d0b0e7f63b..0000000000
--- a/_includes/desktop-install.md
+++ /dev/null
@@ -1,17 +0,0 @@
-> Download Docker Desktop
->
-{% if include.all or include.win -%}
-> [Windows](https://desktop.docker.com/win/main/amd64{{ include.build_path }}Docker%20Desktop%20Installer.exe) ([checksum](https://desktop.docker.com/win/main/amd64{{ include.build_path }}checksums.txt){: target="_blank" rel="noopener" class="_"}) {% if include.all or include.mac or include.linux %} | {% endif %}
-{% endif -%}
-{% if include.all or include.mac -%}
-> [Mac with Intel chip](https://desktop.docker.com/mac/main/amd64{{ include.build_path }}Docker.dmg) ([checksum](https://desktop.docker.com/mac/main/amd64{{ include.build_path }}checksums.txt){: target="_blank" rel="noopener" class="_"}) |
-> [Mac with Apple chip](https://desktop.docker.com/mac/main/arm64{{ include.build_path }}Docker.dmg) ([checksum](https://desktop.docker.com/mac/main/arm64{{ include.build_path }}checksums.txt){: target="_blank" rel="noopener" class="_"}) {% if include.all or include.linux %} | {% endif %}
-{% endif -%}
-{% if include.all or include.linux -%}
-> [Debian](https://desktop.docker.com/linux/main/amd64{{ include.build_path }}docker-desktop-{{ include.version }}-amd64.deb) -
-> [RPM](https://desktop.docker.com/linux/main/amd64{{ include.build_path }}docker-desktop-{{ include.version }}-x86_64.rpm) -
-> [Arch package](https://desktop.docker.com/linux/main/amd64{{ include.build_path }}docker-desktop-{{ include.version }}-x86_64.pkg.tar.zst) ([checksum](https://desktop.docker.com/linux/main/amd64{{ include.build_path }}checksums.txt){: target="_blank" rel="noopener" class="_"})
-{% endif -%}
-{% if include.build_path == "/" -%}
-{: .tip}
-{% endif -%}
diff --git a/_includes/desktop-license-update.md b/_includes/desktop-license-update.md
deleted file mode 100644
index ac9ee242e3..0000000000
--- a/_includes/desktop-license-update.md
+++ /dev/null
@@ -1,8 +0,0 @@
-
-
- Here’s a summary of the key points:
-
- - Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.
- - Otherwise, it requires a paid subscription for professional use.
- - Paid subscriptions are also required for government entities.
- - The Docker Pro, Team, and Business subscriptions include commercial use of Docker Desktop.
diff --git a/_includes/eula-modal.html b/_includes/eula-modal.html
deleted file mode 100644
index f00705cb2f..0000000000
--- a/_includes/eula-modal.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
- Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects. Otherwise, it requires a paid subscription for professional use. Paid subscriptions are also required for government entities. Read the FAQs to learn more.
-
diff --git a/_includes/eula.md b/_includes/eula.md
deleted file mode 100644
index cce88bdc97..0000000000
--- a/_includes/eula.md
+++ /dev/null
@@ -1,6 +0,0 @@
-
-We’ve updated the [Docker Subscription Service Agreement](https://www.docker.com/legal/docker-subscription-service-agreement){: target="_blank" rel="noopener" class="_" id="dkr_docs_relnotes_btl"}. for all versions before 4.0.0 of Docker Desktop.
-Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects. Otherwise, it requires a paid subscription for professional use. Paid subscriptions are also required for government entities. [Read the FAQ] (https://www.docker.com/pricing/faq){: target="_blank" rel="noopener" class="_" id="dkr_docs_relnotes_btl"} to learn more.
-By clicking **Accept and download**, you agree to these [terms](https://www.docker.com/legal/docker-subscription-service-agreement){: target="_blank" rel="noopener" class="_"},
-the [Docker Data Processing Agreement](https://www.docker.com/legal/data-processing-agreement){: target="_blank" rel="noopener" class="_" id="dkr_docs_relnotes_btl"},
-and the [Data Privacy Policy](https://www.docker.com/legal/docker-privacy-policy){: target="_blank" rel="noopener" class="_" id="dkr_docs_relnotes_btl"}.
diff --git a/_includes/footer.html b/_includes/footer.html
deleted file mode 100644
index 1b77f6c998..0000000000
--- a/_includes/footer.html
+++ /dev/null
@@ -1,107 +0,0 @@
- {% comment %}
-
-
-
-
-
-
-
- {% endcomment %}
-
-
-
-
diff --git a/_includes/github-pr.md b/_includes/github-pr.md
deleted file mode 100644
index c9b4d7175d..0000000000
--- a/_includes/github-pr.md
+++ /dev/null
@@ -1,12 +0,0 @@
-{% comment %}
- Generates a Github PR URL from three parameters
-
- Usage:
- {% include github-pr.md org=docker repo=docker pr=12345 %}
-
- If you omit the org or repo, they default to docker.
- If you omit the pr, it defaults to NULL.
-
- Output:
- [#12345](https://github.com/moby/moby/pull/12345)
-{% endcomment %}{% assign org = include.org | default: "docker" %}{% assign repo = include.repo | default: "docker" %}{% assign pr = include.pr | default: NULL %}{% assign github-url="https://github.com" %}{% capture pr-link %}[#{{ pr }}]({{ github-url }}/{{ org }}/{{ repo }}/pull/{{ pr }}){% endcapture %}{{ pr-link | strip_newlines }}
\ No newline at end of file
diff --git a/_includes/head.html b/_includes/head.html
deleted file mode 100644
index 17aac581ad..0000000000
--- a/_includes/head.html
+++ /dev/null
@@ -1,119 +0,0 @@
-{%- if page.title == nil -%}
- {%- comment -%}
- # This is a very hacky way to extract the page title from pages that do not have
- # front-matter yaml, but have a H1 header. We need to take (id-) attributes into
- # account, so some hacking is needed. Taking the following example:
- #
Docker run reference
- #
- # a. split on 'Docker run reference']
- # b. split the last element on 'Docker run reference', '']
- # c. split the first element on '>', which gives us ['
', 'Docker run reference']
- {%- endcomment -%}
- {%- assign a = content | split: '' | last -%}
- {%- assign page_title = c | strip_html | strip | truncatewords: 10 | escape_once -%}
-{%- endif -%}
-{%- if page.description == nil and page.datafile != nil and page.datafile != '' -%}
- {%- assign yaml_data = site.data[page.datafolder][page.datafile] -%}
- {%- if yaml_data.long and yaml_data.long != '' -%}
- {%- assign page_description = page.title | append: ': ' | append: yaml_data.long | strip_html | strip | truncatewords: 30 -%}
- {%- elsif yaml_data.short and yaml_data.short != '' -%}
- {%- assign page_description = page.title | append: ': ' | append: yaml_data.short | strip_html | strip | truncatewords: 30 -%}
- {%- else -%}
- {%- assign page_description = content | strip_html | strip | truncatewords: 30 -%}
- {%- endif -%}
-{%- endif -%}
-
-
- {%- if page.sitemap == false or jekyll.environment != 'production' %}
-
- {%- endif %}
- {%- if jekyll.environment == 'production' -%}
- {%- if site.onetrust_id != '' -%}{%- include analytics/onetrust.html ONETRUST_ID=site.onetrust_id -%}{%- endif -%}
- {%- if site.google_analytics != '' -%}{%- include analytics/google_analytics.html GOOGLE_ID=site.google_analytics -%}{%- endif -%}
- {%- endif -%}
- {{ page.title | default: page_title }} | Docker Documentation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- {%- comment -%}
- We put these scripts in the head section, but use "defer" loading to allow the
- browser to start loading them as soon as possible. Actual execution of deferred
- scripts happens once the HTML is fully parsed.
- see https://flaviocopes.com/javascript-async-defer/#with-defer-in-the-head
- {%- endcomment -%}
- {%- if page.layout == 'landing' -%}
-
-
-
-
- {%- else -%}
-
-
-
-
-
-
-
- {%- endif -%}
- {%- if site.local_search -%}
-
- {%- endif -%}
- {%- include analytics/feedback.html -%}
-
- {% include mermaid.html %}
-
- {%- comment -%}
- preload fonts: https://www.freecodecamp.org/news/web-fonts-in-2018-f191a48367e8/
- we only preload the "woff2" variants, as older formats (woff, eot) are only used
- by older browsers, and we don't optimize for those.
- {%- endcomment -%}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/_includes/header.html b/_includes/header.html
deleted file mode 100644
index 6fdd9f1aa1..0000000000
--- a/_includes/header.html
+++ /dev/null
@@ -1,13 +0,0 @@
-
diff --git a/_includes/image-modal.html b/_includes/image-modal.html
deleted file mode 100644
index 099bd3ce51..0000000000
--- a/_includes/image-modal.html
+++ /dev/null
@@ -1,5 +0,0 @@
-
- Join us in celebrating Docker’s 9th birthday at our next Community All
- Hands on Thursday, March 31, 2022. This virtual event is a
- unique opportunity for the community to come together with Docker
- staff to
- learn, share and collaborate about all things Docker.
-
- We are excited to announce the release of the Tech Preview of Dev Environments as part of Docker Desktop 3.5.0. Docker Dev Environments let you share your work-in-progress code for faster, higher-quality collaboration in just one click.
-
- Docker updates subscription model to deliver scale, speed, and security
-
-
- The updated Docker subscription tiers deliver the productivity and collaboration developers rely on, paired with the security and trust businesses demand. Docker subscription tiers now include Personal, Pro, Team, and Business.
-
With over 50 sessions for developers by developers, watch the latest developer news, trends, and announcements from DockerCon 2022. From the keynote to product demos to technical breakout sessions, hacks, and tips & tricks, there’s something for everyone.
-
\ No newline at end of file
diff --git a/_includes/landing-page/hardened-desktop.html b/_includes/landing-page/hardened-desktop.html
deleted file mode 100644
index 547e3429a9..0000000000
--- a/_includes/landing-page/hardened-desktop.html
+++ /dev/null
@@ -1,19 +0,0 @@
-
-
-
-
- Hardened Docker Desktop for Docker Business customers
-
-
-
Two new security features have been introduced for Docker Business users, Settings Management and Enhanced Container Isolation, as part of Docker Desktop’s new security model.
- Volume Management is now free in Docker Desktop 4.1
-
-
- Thanks for your positive support on the Docker subscription updates. We are now able to deliver more value to all users, starting with making Volume Management available for users on any subscription, including Docker Personal. Update your Docker Desktop to version 4.1 or later to start managing your volumes.
-
- Take a walkthrough that covers writing your first app, data
- storage, networking, and swarms, and ends with your app running
- on production servers in the cloud.
-
- Take a walkthrough that covers writing your first app, data
- storage, networking, and swarms, and ends with your app running
- on production servers in the cloud.
-
- Take a walkthrough that covers writing your first app, data
- storage, networking, and swarms, and ends with your app running
- on production servers in the cloud.
-
- Take a walkthrough that covers writing your first app, data
- storage, networking, and swarms, and ends with your app running
- on production servers in the cloud.
-
- Take a walkthrough that covers writing your first app, data
- storage, networking, and swarms, and ends with your app running
- on production servers in the cloud.
-
- Click here if you are not redirected.
-
-
diff --git a/_plugins/config.rb b/_plugins/config.rb
deleted file mode 100644
index becfc70468..0000000000
--- a/_plugins/config.rb
+++ /dev/null
@@ -1,12 +0,0 @@
-require_relative 'util.rb'
-
-module Jekyll
- class ConfigGenerator < Generator
- safe true
- priority :highest
-
- def generate(site)
- site.config['docs_url'] = get_docs_url
- end
- end
-end
diff --git a/_plugins/fetch_remote.rb b/_plugins/fetch_remote.rb
deleted file mode 100644
index 7993ad1475..0000000000
--- a/_plugins/fetch_remote.rb
+++ /dev/null
@@ -1,147 +0,0 @@
-require 'front_matter_parser'
-require 'git'
-require 'jekyll'
-require 'json'
-require 'octopress-hooks'
-require 'rake'
-
-require_relative 'util.rb'
-
-module Jekyll
- class FetchRemote < Octopress::Hooks::Site
- priority :highest
-
- def self.copy(src, dest)
- if (tmp = Array.try_convert(src))
- tmp.each do |s|
- s = File.path(s)
- yield s, File.join(dest, File.basename(s))
- end
- else
- src = File.path(src)
- if File.directory?(dest)
- yield src, File.join(dest, File.basename(src))
- else
- yield src, File.path(dest)
- end
- end
- end
-
- def self.resolve_line_numbers(first, last)
- if first.nil? && last.nil?
- first = 0
- last = -1
- elsif last.nil?
- last = first
- end
- [first.to_i, last.to_i]
- end
-
- def self.git_init(repo, dir)
- puts " Init repository"
- git = Git.init(dir)
- git.add_remote('origin', repo)
- end
-
- def self.git_fetch(repo, ref, dir)
- unless Dir.exist?(dir)
- FetchRemote.git_init(repo, dir)
- end
- begin
- puts " Open repository"
- git = Git.open(dir)
- git.clean(force: true, d: true)
- rescue => e
- puts " WARNING: #{e}"
- FileUtils.rm_rf(dir)
- FetchRemote.git_init(repo, dir)
- git = Git.open(dir)
- end
- puts " Fetch repository"
- git.fetch('origin', tags: true)
- puts " Checkout repository"
- git.checkout(ref, force: true)
- return git
- end
-
- def pre_read(site)
- beginning_time = Time.now
- puts "Starting plugin fetch_remote.rb..."
-
- site.config['fetch-remote'].each do |entry|
- puts " Repo #{entry['repo']} (#{entry['ref']})"
-
- gituri = Git::URL.parse(entry['repo'])
- clonedir = "#{Dir.tmpdir}/docker-docs-clone#{gituri.path}/#{Digest::SHA256.hexdigest(entry['ref'])}"
- git = FetchRemote.git_fetch("#{entry['repo']}.git", entry['ref'], clonedir)
-
- entry['paths'].each do |path|
- if File.extname(path['dest']) != ""
- if path['src'].size > 1
- raise "Cannot use file destination #{path['dest']} with multiple sources"
- end
- FileUtils.mkdir_p File.dirname(path['dest'])
- else
- FileUtils.mkdir_p path['dest']
- end
-
- puts " Copying files"
-
- # prepare file list to be copied
- files = FileList[]
- path['src'].each do |src|
- if "#{src}".start_with?("!")
- files.exclude(File.join(clonedir, "/"+"#{src}".delete_prefix("!")))
- else
- files.include(File.join(clonedir, "/#{src}"))
- end
- end
-
- files.each do |file|
- FetchRemote.copy(file, path['dest']) do |s, d|
- s = File.realpath(s)
- # traverse source directory
- FileUtils::Entry_.new(s, nil, false).wrap_traverse(proc do |ent|
- file_clean = ent.path.delete_prefix(clonedir).split("/").drop(1).join("/")
- destent = FileUtils::Entry_.new(d, ent.rel, false)
- puts " #{file_clean} => #{destent.path}"
-
- if File.file?(destent.path)
- fmp = FrontMatterParser::Parser.parse_file(destent.path)
- if fmp['fetch_remote'].nil?
- raise "Local file #{destent.path} already exists"
- end
- line_start, line_end = FetchRemote.resolve_line_numbers(fmp['fetch_remote'].kind_of?(Hash) ? fmp['fetch_remote']['line_start'] : nil, fmp['fetch_remote'].kind_of?(Hash) ? fmp['fetch_remote']['line_end'] : nil)
- lines = File.readlines(ent.path)[line_start..line_end]
- File.open(destent.path, "a") { |fow| fow.puts lines.join }
- else
- ent.copy destent.path
- end
-
- next unless File.file?(ent.path) && File.extname(ent.path) == ".md"
- # set edit and issue url and remote info for markdown files in site config defaults
- edit_url = "#{entry['repo']}/edit/#{entry['default_branch']}/#{file_clean}"
- issue_url = "#{entry['repo']}/issues/new?body=File: [#{file_clean}](#{get_docs_url}/#{destent.path.sub(/#{File.extname(destent.path)}$/, '')}/)"
- last_modified_at = git.log.path(file_clean).first.date.strftime(LastModifiedAt::DATE_FORMAT)
- puts " edit_url: #{edit_url}"
- puts " issue_url: #{issue_url}"
- puts " last_modified_at: #{last_modified_at}"
- site.config['defaults'] << {
- "scope" => { "path" => destent.path },
- "values" => {
- "edit_url" => edit_url,
- "issue_url" => issue_url,
- "last_modified_at" => last_modified_at,
- },
- }
- end, proc do |_| end)
- end
- end
- end
- end
-
- end_time = Time.now
- puts "done in #{(end_time - beginning_time)} seconds"
- end
- end
-end
diff --git a/_plugins/fix_swagger.rb b/_plugins/fix_swagger.rb
deleted file mode 100644
index 3a44ea062e..0000000000
--- a/_plugins/fix_swagger.rb
+++ /dev/null
@@ -1,29 +0,0 @@
-require 'jekyll'
-require 'octopress-hooks'
-
-require_relative 'util.rb'
-
-module Jekyll
- class FetchRemote < Octopress::Hooks::Site
- def post_read(site)
- beginning_time = Time.now
- Jekyll.logger.info "Starting plugin fix_swagger.rb..."
-
- # TODO: use dynamic URL from util.get_docs_url instead of hardcoded one
- # but needs to remove first all absolute URLs in our code base.
- docs_url = "https://docs.docker.com"
-
- files = Dir.glob(%w[./docker-hub/api/*.yaml ./engine/api/*.yaml])
- Jekyll.logger.info " Fixing up #{files.size} swagger file(s)..."
- files.each do |f|
- Jekyll.logger.info " #{f}"
- text = File.read(f)
- replace = text.gsub(docs_url, "")
- File.open(f, "w") { |f2| f2.puts replace }
- end
-
- end_time = Time.now
- Jekyll.logger.info "done in #{(end_time - beginning_time)} seconds"
- end
- end
-end
diff --git a/_plugins/fix_url.rb b/_plugins/fix_url.rb
deleted file mode 100644
index d57750e2cc..0000000000
--- a/_plugins/fix_url.rb
+++ /dev/null
@@ -1,28 +0,0 @@
-require 'jekyll'
-require 'octopress-hooks'
-
-require_relative 'util.rb'
-
-module Jekyll
- class FetchRemote < Octopress::Hooks::Site
- def post_write(site)
- beginning_time = Time.now
- Jekyll.logger.info "Starting plugin fix_url.rb..."
-
- # TODO: use dynamic URL from util.get_docs_url instead of hardcoded one
- # but needs to remove first all absolute URLs in our code base.
- docs_url = "https://docs.docker.com"
-
- files = Dir.glob("#{site.dest}/**/*.html")
- Jekyll.logger.info " Fixing up URLs in #{files.size} html file(s) to be relative"
- files.each do|f|
- text = File.read(f)
- replace = text.gsub(/(]* href=\")#{docs_url}/, '\1')
- File.open(f, "w") { |f2| f2.puts replace }
- end
-
- end_time = Time.now
- Jekyll.logger.info "done in #{(end_time - beginning_time)} seconds"
- end
- end
-end
diff --git a/_plugins/last_modified_at.rb b/_plugins/last_modified_at.rb
deleted file mode 100644
index 05b2225d4d..0000000000
--- a/_plugins/last_modified_at.rb
+++ /dev/null
@@ -1,65 +0,0 @@
-require 'git'
-require 'jekyll'
-require 'octopress-hooks'
-
-module Jekyll
- class LastModifiedAt < Octopress::Hooks::Site
- DATE_FORMAT = '%Y-%m-%d %H:%M:%S %z'
-
- def current_last_modified_at(site, page)
- if page.data.key?('last_modified_at')
- return page.data['last_modified_at']
- end
- site.config['defaults'].map do |set|
- if set['values'].key?('last_modified_at') && set['scope']['path'].include?(page.relative_path)
- return set['values']['last_modified_at']
- end
- end.compact
- nil
- end
-
- def pre_render(site)
- beginning_time = Time.now
- Jekyll.logger.info "Starting plugin last_modified_at.rb..."
-
- git = Git.open(site.source)
- use_file_mtime = get_docs_url == "http://localhost:4000" && ENV['DOCS_ENFORCE_GIT_LOG_HISTORY'] == "0"
- site.pages.sort!{|l,r| l.relative_path <=> r.relative_path }.each do |page|
- next if page.relative_path == "redirect.html"
- next unless File.extname(page.relative_path) == ".md" || File.extname(page.relative_path) == ".html"
- page.data['last_modified_at'] = current_last_modified_at(site, page)
- set_mode = "frontmatter"
- path_override = ""
- if page.data['last_modified_at'].nil?
- page_relative_path = page.relative_path
- if page.data.key?('datafolder') && page.data.key?('datafile')
- page_relative_path = File.join('_data', page.data['datafolder'], "#{page.data['datafile']}.yaml")
- path_override = "\n override: #{page_relative_path}"
- end
- begin
- if use_file_mtime
- # Use file's mtime for local development
- page.data['last_modified_at'] = File.mtime(page_relative_path).strftime(DATE_FORMAT)
- set_mode = "mtime"
- else
- page.data['last_modified_at'] = git.log.path(page_relative_path).first.date.strftime(DATE_FORMAT)
- set_mode = "git"
- end
- rescue => e
- begin
- page.data['last_modified_at'] = File.mtime(page_relative_path).strftime(DATE_FORMAT)
- set_mode = "mtime"
- rescue => e
- page.data['last_modified_at'] = Time.now.strftime(DATE_FORMAT)
- set_mode = "rescue"
- end
- end
- end
- puts" #{page.relative_path}#{path_override}\n last_modified_at(#{set_mode}): #{page.data['last_modified_at']}"
- end
-
- end_time = Time.now
- Jekyll.logger.info "done in #{(end_time - beginning_time)} seconds"
- end
- end
-end
diff --git a/_plugins/pageless_redirects.rb b/_plugins/pageless_redirects.rb
deleted file mode 100644
index 3d3505d9de..0000000000
--- a/_plugins/pageless_redirects.rb
+++ /dev/null
@@ -1,38 +0,0 @@
-require 'jekyll'
-require 'octopress-hooks'
-
-module Jekyll
- class RedirectPage < Jekyll::Page
- def initialize(site, src, redirect_to)
- puts " #{src} => #{redirect_to}"
- @site = site
- @base = site.source
- @dir = src
- @name = "index.html"
- process(@name)
- @data = {
- "sitemap" => false,
- "redirect_to" => redirect_to
- }
- end
- end
-
- class PagelessRedirects < Octopress::Hooks::Site
- def post_read(site)
- beginning_time = Time.now
- puts "Starting plugin pageless_redirects.rb..."
-
- if File.file?("_redirects.yml")
- rd = YAML.load_file("_redirects.yml")
- rd.each do |redirect_to, srcs|
- srcs.each do |src|
- site.pages << RedirectPage.new(site, src, redirect_to)
- end
- end
- end
-
- end_time = Time.now
- puts "done in #{(end_time - beginning_time)} seconds"
- end
- end
-end
diff --git a/_plugins/relative_links_filter.rb b/_plugins/relative_links_filter.rb
deleted file mode 100644
index 4677836474..0000000000
--- a/_plugins/relative_links_filter.rb
+++ /dev/null
@@ -1,118 +0,0 @@
-module Jekyll
- # This custom Filter is used to fix up links to markdown pages that weren't
- # resolved by Jekyll (or the "jekyll-relative-links" plugin). We need this hack
- # to work around a bug in the "jekyll-relative-links" plugin;
- #
- # As reported in https://github.com/benbalter/jekyll-relative-links/issues/54,
- # (relative) links to markdown pages in includes are not processed by Jekyll.
- # This means that our reference pages (which use includes) have broken links.
- # We could work around this by modifying the markdown for those pages to use
- # "absolute" "html" links (/link/to/other/page/#some-anchor), but doing so
- # would render the links broken when viewed on GitHub. Instead, we're fixing
- # them up here, until the bug is fixed upstream.
- #
- # A second bug (https://github.com/benbalter/jekyll-relative-links/issues/61),
- # causes (relative) links to markdown pages to not be resolved if the link's
- # caption/title is wrapped. This bug is currently not handled by this plugin,
- # but could possibly be addressed by modifying the TITLE_REGEX.
- #
- # This plugin is based on code in the jekyll-relative-links plugin, but takes
- # some shortcuts;
- #
- # - We use the code from jekyll-relative-links plugin to find/extract links
- # on the page
- # - Relative links are converted to absolute links, using the path of the
- # markdown source file that's passed as argument
- # - After conversion to an absolute link, we strip the ".md" extension; no
- # attempt is made to resolve the file that's linked to. This is different
- # from the jekyll-relative-links plugin, which _does_ resolve the linked
- # file. This functionality could be added in future by someone who has
- # more experience with Ruby.
- module RelativeLinksFilter
- attr_accessor :site, :config
-
- # Use Jekyll's native relative_url filter
- include Jekyll::Filters::URLFilters
-
- LINK_TEXT_REGEX = %r!(.*?)!.freeze
- FRAGMENT_REGEX = %r!(#.+?)?!.freeze
- TITLE_REGEX = %r{(\s+"(?:\\"|[^"])*(?/", "#{get_docs_url}/")
- Jekyll.logger.info " Replacing '/' with '#{get_docs_url}/' in #{sitemap_path}"
- File.open(sitemap_path, "w") { |file| file.puts replace }
- end
-
- end_time = Time.now
- Jekyll.logger.info "done in #{(end_time - beginning_time)} seconds"
-end
diff --git a/_plugins/util.rb b/_plugins/util.rb
deleted file mode 100644
index d8f118d571..0000000000
--- a/_plugins/util.rb
+++ /dev/null
@@ -1,5 +0,0 @@
-def get_docs_url
- # DEPLOY_URL is from Netlify for preview
- # https://docs.netlify.com/configure-builds/environment-variables/#deploy-urls-and-metadata
- ENV['DEPLOY_URL'] || ENV['DOCS_URL'] || 'https://docs.docker.com'
-end
diff --git a/_scss/_DS-colors.scss b/_scss/_DS-colors.scss
deleted file mode 100644
index 246f1f919f..0000000000
--- a/_scss/_DS-colors.scss
+++ /dev/null
@@ -1,99 +0,0 @@
-// This file defines two palettes and is taken from Docker's Design System. The light palette should only be used
-// in light mode, and vice versa. In general, if you use one of the colors
-// in light mode, you should the same-named color in the dark palette in
-// dark mode.
-
-$white: #FFFFFF;
-$light-page-background: #F9F9FA;
-$dark-palette-background: #1C262D;
-$grey-100: #EFEFF2;
-$black: #000000;
-
-
-// light palette contrast colors:
-
-$light-grey-200: #E1E2E6;
-$light-grey-300: #C4C8D1;
-$light-grey-400: #8993A5;
-$light-grey-500: #677285;
-$light-grey-600: #505968;
-$light-grey-700: #393F49;
-$light-grey-800: #17191E;
-$light-red-300: #EEA3A5;
-$light-red-400: #E25D68;
-$light-red-500: #D52536;
-$light-red-600: #B72132;
-$light-red-700: #8B1924;
-$light-viole-200: #E9D4FF;
-$light-viole-300: #C9A6FF;
-$light-viole-400: #9860FF;
-$light-viole-500: #7D2EFF;
-$light-viole-600: #6D00EB;
-$light-viole-700: #5700BB;
-$light-viole-800: #220041;
-$light-blue-100: #E5F2FC;
-$light-blue-200: #C0E0FA;
-$light-blue-300: #8BC7F5;
-$light-blue-400: #1C90ED;
-$light-blue-500: #086DD7;
-$light-blue-600: #0055BD;
-$light-blue-700: #1144A6;
-$light-blue-800: #00084D;
-$light-green-200: #C6EAE1;
-$light-green-300: #88D5C0;
-$light-green-400: #3BA08D;
-$light-green-500: #2E7F74;
-$light-green-600: #1E6C5F;
-$light-green-700: #185A51;
-$light-amber-100: #FFF4DC;
-$light-amber-200: #FCE1A9;
-$light-amber-300: #FBB552;
-$light-amber-400: #DD7805;
-$light-amber-500: #B85504;
-
-// dark palette contrast colors:
-
-$dark-grey-100: #141B1F;
-$dark-grey-200: #27343E;
-$dark-grey-300: #364754;
-$dark-grey-400: #465C6E;
-$dark-grey-500: #7794AB;
-$dark-grey-600: #94ABBC;
-$dark-grey-700: #ADBECB;
-$dark-grey-800: #C4D0DA;
-$dark-red-200: #951C2F;
-$dark-red-300: #BC233C;
-$dark-red-400: #D1334C;
-$dark-red-500: #ED5669;
-$dark-red-600: #E96C7C;
-$dark-red-700: #EA8E9A;
-$dark-red-800: #F0AAB4;
-$dark-viole-100: #491D7B;
-$dark-viole-200: #5F25A0;
-$dark-viole-300: #7835D3;
-$dark-viole-400: #8A53EC;
-$dark-viole-500: #A371FC;
-$dark-viole-600: #B38BFC;
-$dark-viole-700: #C5A6FD;
-$dark-viole-800: #D4BDFE;
-$dark-blue-100: #06326D;
-$dark-blue-200: #08489B;
-$dark-blue-300: #1760CA;
-$dark-blue-400: #2673E3;
-$dark-blue-500: #3391EE;
-$dark-blue-600: #55A4F1;
-$dark-blue-700: #7CB9F4;
-$dark-blue-800: #98C8F6;
-$dark-green-200: #155048;
-$dark-green-300: #176254;
-$dark-green-400: #228375;
-$dark-green-500: #2AA391;
-$dark-green-600: #3CC1AD;
-$dark-green-700: #7ACCC3;
-$dark-green-800: #A5DDD6;
-$dark-amber-300: #AF560A;
-$dark-amber-400: #CD6A0A;
-$dark-amber-500: #ED8D25;
-$dark-amber-600: #F6A650;
-$dark-amber-700: #F8B974;
-$dark-amber-800: #FAC892;
diff --git a/_scss/_base.scss b/_scss/_base.scss
deleted file mode 100755
index 25993498bd..0000000000
--- a/_scss/_base.scss
+++ /dev/null
@@ -1,32 +0,0 @@
-html {
- font-family: $font;
- -webkit-text-size-adjust: 100%;
- -ms-text-size-adjust: 100%;
- -moz-osx-font-smoothing: grayscale;
- -webkit-font-smoothing: antialiased;
- color-scheme: light;
-}
-
-body {
- background-color: $bg-body;
- color: $body-text;
- font-family: $font;
- font-size: $body-text-size;
- margin: 0;
- padding: 0;
- overflow-x: hidden;
-}
-
-a {
- color: $primary-links;
- text-decoration: none;
- outline: none;
- &:hover, &:focus {
- opacity: .8;
- text-decoration: none;
- }
-}
-blockquote {
- /* Override Bootstrap's style */
- border-left: none;
-}
\ No newline at end of file
diff --git a/_scss/_breakpoint.scss b/_scss/_breakpoint.scss
deleted file mode 100644
index 587382c619..0000000000
--- a/_scss/_breakpoint.scss
+++ /dev/null
@@ -1,39 +0,0 @@
-$sm-min-width: 576px;
-$md-min-width: 768px;
-$lg-min-width: 992px;
-$xl-min-width: 1200px;
-
-@mixin sm-width {
- @media (min-width: $sm-min-width) {
- @content;
- }
-}
-
-@mixin before-md-width {
- @media (max-width: $md-min-width - 1) {
- @content;
- }
-}
-
-@mixin md-width {
- @media (min-width: $md-min-width) {
- @content;
- }
-}
-
-@mixin before-lg-width {
- @media (max-width: $lg-min-width - 1) {
- @content;
- }
-}
-
-@mixin lg-width {
- @media (min-width: $lg-min-width) {
- @content;
- }
-}
-@mixin xl-width {
- @media (min-width: $xl-min-width) {
- @content;
- }
-}
diff --git a/_scss/_buttons.scss b/_scss/_buttons.scss
deleted file mode 100755
index ca13c7c012..0000000000
--- a/_scss/_buttons.scss
+++ /dev/null
@@ -1,71 +0,0 @@
-ul.buttons {
- list-style: none;
- width: 450px;
- margin: 0 auto;
-}
-
-a.button {
- color: #fff;
-}
-
-a.button.outline-btn {
- color: $primary-links;
- float: none;
- display: inline-block;
-}
-
-a.button.outline-btn.min-hgt {
- min-height: 85px;
-}
-
-.button {
- display: inline-block;
- margin: 10px 10px 10px 0;
- font-family: $buttons;
- padding: 12px 35px;
- min-width: 200px;
- box-shadow: 0 1px 0 0 rgba(0, 0, 0, 0.1);
- text-align: center;
- white-space: nowrap;
- &:hover {
- color: #fff;
- opacity: 0.7;
- }
-}
-
-.primary-btn {
- background: $primary-links;
- border: 1px solid rgba(0, 0, 0, 0.1);
- border-radius: 4px;
-}
-
-/*
-.secondary-btn {
- background-color: rgba(255, 255, 255, 0.2);
- box-shadow: 0 1px 0 0 rgba(0, 0, 0, 0.1);
- border: 1px solid rgba(255, 255, 255, 0.1);
- text-shadow: 0 1px rgba(0, 0, 0, 0.2);
-}
-
-.transparent-btn {
- background-color: rgba(0, 0, 0, 0.2);
- box-shadow: 0 1px 0 0 rgba(0, 0, 0, 0.1);
- border: 1px solid rgba(0, 0, 0, 0.1);
- text-shadow: 0 1px rgba(0, 0, 0, 0.2);
-}
-*/
-
-.outline-btn {
- background: #fff;
- border: 1px solid $light-blue-400;
- margin: 0;
- &:hover {
- color: $light-blue-400;
- }
-}
-
-//.secondary-btn:hover,
-.primary-btn:hover,
-.outline-btn:hover {
- opacity: 0.8;
-}
diff --git a/_scss/_color-palette-v2.scss b/_scss/_color-palette-v2.scss
deleted file mode 100644
index 0c18da13c5..0000000000
--- a/_scss/_color-palette-v2.scss
+++ /dev/null
@@ -1,25 +0,0 @@
-/* This palette is deprecated */
-
-$red-90: #9e1011;
-
-$marine-10: #9fd1f9;
-$marine-50: #007bff;
-$marine-90: #002c66;
-
-$grey-10: #d7dade;
-
-$blue-60: #2496ed;
-$blue-70: #1282d7;
-$blue-80: #076cad;
-
-$orange-10: #fef5c3;
-$orange-20: #f9e3ae;
-$orange-90: #d4611d;
-
-$white-0: #ffffff;
-$white-5: #fafafb;
-$white-10: #f7f7f8;
-$white-15: #f2f3f5;
-$white-25: #e9ebee;
-
-$black-0: #0f161e;
diff --git a/_scss/_color-palette-v3.scss b/_scss/_color-palette-v3.scss
deleted file mode 100644
index f4f0040e69..0000000000
--- a/_scss/_color-palette-v3.scss
+++ /dev/null
@@ -1,116 +0,0 @@
-//This has now been deprecated. See DS-colors instead//
-
-// This file defines two palettes. The light palette should only be used
-// in light mode, and vice versa. In general, if you use one of the colors
-// in light mode, you should the same-named color in the dark palette in
-// dark mode.
-
-// light palette contrast colors:
-// 100-400: black
-// 500-800: white
-
-$light-palette-background: #F9F9FA;
-
-$light-palette-amber-100: #FFF6E2;
-$light-palette-amber-200: #FCE1A9;
-$light-palette-amber-300: #FBB552;
-$light-palette-amber-400: #DD7805;
-$light-palette-amber-500: #B85504;
-$light-palette-amber-600: #AA4409;
-$light-palette-amber-700: #893607;
-$light-palette-amber-800: #421A02;
-$light-palette-blue-100: #E8F4FD;
-$light-palette-blue-200: #C0E0FA;
-$light-palette-blue-300: #8BC7F5;
-$light-palette-blue-400: #1C90ED;
-$light-palette-blue-500: #116ED0;
-$light-palette-blue-600: #0055BD;
-$light-palette-blue-700: #1144A6;
-$light-palette-blue-800: #00084D;
-$light-palette-green-100: #F3FAF9;
-$light-palette-green-200: #C6EAE1;
-$light-palette-green-300: #88D5C0;
-$light-palette-green-400: #3BA08D;
-$light-palette-green-500: #2E7F74;
-$light-palette-green-600: #1E6C5F;
-$light-palette-green-700: #185A51;
-$light-palette-green-800: #0C2C28;
-$light-palette-grey-100: #EAEAED;
-$light-palette-grey-200: #E1E2E6;
-$light-palette-grey-300: #C4C8D1;
-$light-palette-grey-400: #8993A5;
-$light-palette-grey-500: #677285;
-$light-palette-grey-600: #505968;
-$light-palette-grey-700: #393F49;
-$light-palette-grey-800: #17191E;
-$light-palette-red-100: #FEEFEF;
-$light-palette-red-200: #F6CFD0;
-$light-palette-red-300: #EEA3A5;
-$light-palette-red-400: #E25D68;
-$light-palette-red-500: #D52536;
-$light-palette-red-600: #B72132;
-$light-palette-red-700: #8B1924;
-$light-palette-red-800: #350A10;
-$light-palette-violet-100: #F7ECFF;
-$light-palette-violet-200: #E9D4FF;
-$light-palette-violet-300: #C9A6FF;
-$light-palette-violet-400: #9860FF;
-$light-palette-violet-500: #7D2EFF;
-$light-palette-violet-600: #6D00EB;
-$light-palette-violet-700: #5700BB;
-$light-palette-violet-800: #220041;
-
-// dark palette contrast colors:
-// 100-400: white
-// 500-800: black
-
-$dark-palette-background: #1C262D;
-
-$dark-palette-amber-100: #672805;
-$dark-palette-amber-200: #7B3606;
-$dark-palette-amber-300: #944307;
-$dark-palette-amber-400: #AF560A;
-$dark-palette-amber-500: #CD6A0A;
-$dark-palette-amber-600: #ED8D25;
-$dark-palette-amber-700: #F6A650;
-$dark-palette-amber-800: #F8B974;
-$dark-palette-blue-100: #0B1B46;
-$dark-palette-blue-200: #06326D;
-$dark-palette-blue-300: #084391;
-$dark-palette-blue-400: #1557B8;
-$dark-palette-blue-500: #116ED0;
-$dark-palette-blue-600: #3391EE;
-$dark-palette-blue-700: #55A4F1;
-$dark-palette-blue-800: #7CB9F4;
-$dark-palette-green-100: #0D342E;
-$dark-palette-green-200: #11423B;
-$dark-palette-green-300: #145348;
-$dark-palette-green-400: #1A655A;
-$dark-palette-green-500: #228375;
-$dark-palette-green-600: #2AA391;
-$dark-palette-green-700: #3CC1AD;
-$dark-palette-green-800: #7ACCC3;
-$dark-palette-grey-100: #141B1F;
-$dark-palette-grey-200: #27343E;
-$dark-palette-grey-300: #364754;
-$dark-palette-grey-400: #465C6E;
-$dark-palette-grey-500: #7794AB;
-$dark-palette-grey-600: #94ABBC;
-$dark-palette-grey-700: #ADBECB;
-$dark-palette-grey-800: #C4D0DA;
-$dark-palette-red-100: #58111B;
-$dark-palette-red-200: #741624;
-$dark-palette-red-300: #951C2F;
-$dark-palette-red-400: #BC233C;
-$dark-palette-red-500: #C32438;
-$dark-palette-red-600: #DD4659;
-$dark-palette-red-700: #E36676;
-$dark-palette-red-800: #EA8E9A;
-$dark-palette-violet-100: #341458;
-$dark-palette-violet-200: #491D7B;
-$dark-palette-violet-300: #5F25A0;
-$dark-palette-violet-400: #8032D6;
-$dark-palette-violet-500: #8A53EC;
-$dark-palette-violet-600: #A371FC;
-$dark-palette-violet-700: #B38BFC;
-$dark-palette-violet-800: #C5A6FD;
diff --git a/_scss/_content.scss b/_scss/_content.scss
deleted file mode 100755
index 70fe8f07e5..0000000000
--- a/_scss/_content.scss
+++ /dev/null
@@ -1,205 +0,0 @@
-
-.content, p {
- line-height: 24px;
- clear: both;
-
- img {
- display: block;
- height: auto;
- max-width: 100%;
- }
-}
-
-/*
- * Code formatting *************************************************************
- */
-pre, code {
- background-color: $light-page-background!important;
- color: $light-blue-600 !important;
-}
-
-pre {
- border: 0;
- border-radius: 4px;
- display: block;
- padding: 20.5px!important;
- margin: 0 0 10px;
- font-size: 13px;
- line-height: 1.42857143;
- word-break: normal !important;
- word-wrap: break-word;
-
- code {
- overflow-x: auto;
- overflow-wrap: normal;
- white-space: pre;
- }
-}
-
-code {
- border-radius: 2px;
- font-size: 90%;
- padding: 3px 7px;
- overflow-x: scroll;
-}
-
-.highlighter-rouge {
- margin: 15px 0;
- position: relative;
-
- button.copy {
- position: absolute;
- top: 10px;
- right: 10px;
- background: none;
- border: none;
- }
-}
-
-/*
- * Guides : components *********************************************************
- */
-
-.component-container {
- padding: 0;
- margin: 0 0 50px;
- width: 100%;
-
- .row {
- display: flex;
- flex-wrap: wrap;
- }
-
- // "get-docker" tiles
- .row > .block {
- display: flex;
- flex-direction: column;
- padding: 10px;
- }
-
- .component {
- padding: 15px 25px 15px 15px;
- text-align: center;
- height: 100%;
- width: 100%;
- background: $bg-component;
- img {
- height: 70px;
- }
- .component-icon {
- display: flex;
- justify-content: center;
- }
- h2 {
- font-size: 18px;
- }
- h2, h3, p {
- margin: 0;
- }
- }
-}
-
-a.anchorLink {
- font-size: 0.5em;
- margin-left: 5px;
- visibility: hidden;
-}
-
-h1:hover > a.anchorLink,
-h2:hover > a.anchorLink,
-h3:hover > a.anchorLink
-{
- visibility: visible;
-}
-
-a.glossary {
- color: $body-text;
- outline: none;
- &:hover {
- opacity: 1;
- }
-}
-
-a.accept-eula {
- font-weight: bold;
-}
-
-/* Style the Image Used to Trigger the Modal */
-main img {
- border-radius: 5px;
- cursor: pointer;
- transition: 0.3s;
-}
-
-main img:hover {opacity: 0.7;}
-
-/* The Modal (background) */
-.modal1 {
- display: none; /* Hidden by default */
- position: fixed; /* Stay in place */
- z-index: 1; /* Sit on top */
- padding-top: 100px; /* Location of the box */
- left: 0;
- top: 0;
- width: 100%; /* Full width */
- height: 100%; /* Full height */
- overflow: auto; /* Enable scroll if needed */
- background-color: rgb(0,0,0); /* Fallback color */
- background-color: rgba(0,0,0,0.9); /* Black w/ opacity */
-}
-
-/* Modal Content (Image) */
-.modal-content1 {
- margin: auto;
- display: block;
- width: 90%;
- top:20px;
-}
-
-/* Caption of Modal Image (Image Text) - Same Width as the Image */
-#img-modal-caption1 {
- margin: 15px auto;
- display: block;
- width: 80%;
- max-width: 700px;
- text-align: center;
- color: #ccc;
- padding: 10px 0;
- height: 150px;
-}
-
-/* Add Animation - Zoom in the Modal */
-.modal-content1, #img-modal-caption1 {
- animation-name: zoom;
- animation-duration: 0.6s;
-}
-
-@keyframes zoom {
- from {transform:scale(0)}
- to {transform:scale(1)}
-}
-
-/* The Close Button */
-#img-modal-close1 {
- font-size: 40px;
- font-weight: bold;
- color: #f1f1f1;
- transition: 0.3s;
- margin-right: 10px;
-}
-
-#img-modal-close1:hover,
-#img-modal-close1:focus {
- color: #bbb;
- text-decoration: none;
- cursor: pointer;
-}
-
-/* 100% Image Width on Smaller Screens */
-@media only screen and (max-width: 700px){
- .modal-content {
- width: 100%;
- }
-}
-
-
diff --git a/_scss/_github.scss b/_scss/_github.scss
deleted file mode 100755
index b1135a6d99..0000000000
--- a/_scss/_github.scss
+++ /dev/null
@@ -1,104 +0,0 @@
-/*
-
-github.com style (c) Vasily Polovnyov
-
-*/
-
-.hljs {
- display: block;
- overflow-x: auto;
- padding: 0.5em;
- // color: #333;
-}
-
-.hljs-comment,
-.hljs-quote {
- // color: #998;
- font-style: italic;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-subst {
- // color: #333;
- font-weight: bold;
-}
-
-/*
-.hljs-number,
-.hljs-literal,
-.hljs-variable,
-.hljs-template-variable,
-.hljs-tag .hljs-attr {
- color: #008080;
-}
-*/
-
-.hljs-string,
-.hljs-doctag {
- color: #d14;
-}
-
-.hljs-title,
-.hljs-section,
-.hljs-selector-id {
- // color: #900;
- font-weight: bold;
-}
-
-.hljs-subst {
- font-weight: normal;
-}
-
-.hljs-type,
-.hljs-class .hljs-title {
- // color: #458;
- font-weight: bold;
-}
-
-.hljs-tag,
-.hljs-name,
-.hljs-attribute {
- // color: #000080;
- font-weight: normal;
-}
-
-/*
-.hljs-regexp,
-.hljs-link {
- color: #009926;
-}
-
-.hljs-symbol,
-.hljs-bullet {
- color: #990073;
-}
-
-.hljs-built_in,
-.hljs-builtin-name {
- color: #0086b3;
-}
-*/
-
-.hljs-meta {
- // color: #999;
- font-weight: bold;
-}
-
-/*
-.hljs-deletion {
- background: #fdd;
-}
-
-.hljs-addition {
- background: #dfd;
-}
-*/
-
-.hljs-emphasis {
- font-style: italic;
-}
-
-.hljs-strong {
- font-weight: bold;
-}
\ No newline at end of file
diff --git a/_scss/_landing.scss b/_scss/_landing.scss
deleted file mode 100644
index 49ca5143cb..0000000000
--- a/_scss/_landing.scss
+++ /dev/null
@@ -1,341 +0,0 @@
-$dark-blue: #002c66;
-
-body.landing {
- background-color: $bg-body-landing;
-
- h2, h5, h6 {
- font-family: $headings-landing;
- }
-
- section {
- margin-top: 40px;
- margin-bottom: 40px;
- }
-
- .header {
- // Container holds both the top-navigation bar (div.navbar-header), and
- // the "hamburger menu" (div.navbar-collapse)
- >.container {
- background-color: $bg-header;
- }
-
- @include md-width {
- .navbar-collapse.collapse {
- display: flex !important;
-
- ul:first-of-type {
- flex: 1;
- display: flex;
- justify-content: center;
- }
- }
- }
-
- @include before-lg-width {
- .container {
- width: unset;
- }
- }
-
- a, .toggle-mode {
- color: white;
- }
-
- .navbar-brand {
- padding-top: 12px;
- padding-bottom: 12px;
- }
-
- .navbar-toggle {
- margin: 15px;
- height: 20px;
- display: block;
-
- @include md-width {
- display: none;
- }
- }
-
- .toggle-mode {
- margin-top: 15px;
-
- .icon {
- margin-top: 4px;
- }
- }
- }
-
- .hero {
- padding-top: 20px;
-
- h2 {
- font-size: 32px;
- line-height: 32px;
- margin-bottom: 14px;
- }
-
- input {
- font-size: 18px;
- height: 50px;
- line-height: 24px;
- padding: 13px 20px;
-
- &:focus {
- box-shadow: none;
- outline: none;
- }
- }
-
- #autocompleteResults {
- left: 14px;
- right: 14px;
- width: unset;
-
- @include before-lg-width {
- padding: 0;
- }
- }
- }
-
- .card-holder {
- padding: 7.5px;
- }
-
- .video-item {
- display: flex;
- flex-direction: row;
- align-items: center;
- margin-top: 6.5px;
- margin-bottom: 6.5px;
-
- .video-image {
- margin-right: 13px;
- }
-
- .video-title {
- flex: 1;
- }
- }
-
- %icon-card {
- background-image: none;
- background-origin: content-box;
- background-repeat: no-repeat;
- background-size: auto 35px;
-
- @include sm-width { background-size: auto 40px; min-height: 220px; }
- @include md-width { background-size: auto 50px }
- @include lg-width { background-size: auto 60px }
-
- .title {
- margin-top: 0;
- margin-left: 60px;
- @include sm-width { margin-left: 0; margin-top: 60px }
- @include md-width { margin-left: 0; margin-top: 72px }
- @include lg-width { margin-left: 0; margin-top: 90px }
- }
-
- p {
- margin-left: 60px;
- @include sm-width { margin-left: 0 }
- }
- }
-
- $icons: rocket, download-docker, guides, language-guides, whats-new, manuals, reference;
-
- .card {
- color: $body-text;
- background-color: $bg-card;
- box-shadow: 0 3px 6px rgba(11, 33, 74, 0.09),
- 0 -2px 2px rgba(11, 33, 74, 0.03);
- padding: 24px 36px;
- min-height: 100px;
-
- @include sm-width {
- min-height: 185px;
- }
-
- @each $icon in $icons {
- &.#{$icon} {
- @extend %icon-card;
- background-image: url("/assets/images/#{$icon}.svg");
- }
- }
-
- .title {
- font-size: 16px;
- line-height: 16px;
- margin: 10px 0;
-
- @include sm-width {
- font-size: 18px;
- line-height: 18px;
- margin: 6px 0;
- }
-
- @include md-width {
- font-size: 20px;
- line-height: 20px;
- margin: 6px 0;
- }
-
- @include lg-width {
- font-size: 22px;
- line-height: 22px;
- margin: 8px 0;
- }
- }
-
- p {
- font-size: 14px;
- line-height: 19px;
- }
- }
-
- a.card {
- display: block;
- transition: transform 150ms ease-in-out;
-
- &:hover {
- opacity: 1;
- transform: scale(1.01);
- }
-
- &[target=_blank] {
- background-image: url(/assets/images/arrow.svg);
- background-position: top 10px right 10px;
- background-repeat: no-repeat;
- background-size: 15px 15px;
- }
- }
-
- .cardlet {
- background-color: $grey-100;
- padding: 24px 36px;
-
- .title {
- font-family: "Roboto", sans-serif;
- line-height: 22px;
- font-size: 22px;
- }
-
- p {
- font-size: 14px;
- line-height: 18px;
- }
- }
-
- section.cta-banner {
- background-color: $dark-blue;
- padding: 65px 0;
-
- h2, h5, p {
- color: white;
- }
-
- text-align: center;
-
- @include md-width {
- text-align: left;
- }
-
- img {
- margin-bottom: 10px;
- max-height: 190px;
- }
-
- h2 {
- font-size: 32px;
- line-height: 37px;;
- }
-
- a.btn {
- background: $white;
- color: $dark-blue-400;
- font-size: 17px;
- margin-top: 20px;
- padding: 15px 30px;
-
- img {
- margin: 0;
- }
-
- &.slack-button {
- background: white;
- color: $dark-blue;
- padding: 2px 25px 2px 10px;
- }
- }
- }
-
- .tab-section {
- .title {
- font-family: "Roboto", sans-serif;
- font-size: 22px;
- }
-
- ul.nav.nav-tabs li a, h5, h6 {
- font-family: 'Roboto', sans-serif;
- font-size: 18px;
- }
-
- ul.nav.nav-tabs {
- margin-bottom: 30px;
-
- li a {
- cursor: pointer;
- padding: 10px 3px;
- @include sm-width { padding: 10px 15px; }
- }
-
- li.active a {
- background-color: inherit;
- border: none;
- border-bottom: 5px solid $dark-blue-500;
- }
- }
-
- .row[data-tab] {
- display: none;
-
- &[data-os] .only-win,
- &[data-os] .only-mac {
- display: none;
- }
-
- &[data-os="win"] .only-win,
- &[data-os="mac"] .only-mac {
- display: initial;
- }
-
- &[data-os="win"] p.only-win,
- &[data-os="mac"] p.only-mac {
- display: block;
- }
-
- &.active {
- display: block;
- }
-
- .image {
- background-position: center;
- background-size: contain;
- background-repeat: no-repeat;
- margin-top: 15px;
- width: 130px;
- height: 130px;
- margin-left: auto;
- margin-right: auto;
- }
- }
- }
-
- footer {
- background-color: $bg-footer-landing;
- margin-top: 130px;
-
- a, p {
- color: white;
- }
- }
-}
diff --git a/_scss/_layout.scss b/_scss/_layout.scss
deleted file mode 100755
index 8a9a218bf0..0000000000
--- a/_scss/_layout.scss
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * branding ********************************************************************
- */
-
-.logo {
- margin: 12px 10px 0 10px;
- width: 160px;
- display: none;
-
- @include lg-width {
- display: initial;
- }
-}
-.logo-mobile {
- a {
- float: left;
-
- img {
- margin: 12px 15px;
- height: 30px;
- }
- }
-
- @include lg-width {
- display: none;
- }
-}
-
-/*
- * Header **********************************************************************
- */
-
-.header {
- background-color: $bg-header;
- position: relative;
- z-index: 1;
- transition: all 0.1s ease;
- border: unset;
- border-radius: unset;
- height: unset;
-}
-
-.columns {
- flex-direction: column;
-}
-
-.col-nav {
- order: -1;
-}
-
-.col-body {
- display: flex;
- flex-direction: row;
- flex: 1;
- min-height: 555px;
-}
-
-.col-content {
- flex: 1;
- padding: $top-navigation-height 20px 40px 40px;
- max-width: 1024px;
- min-width: 300px;
- min-height: 500px;
-}
-
-.col-nav,
-.col-toc {
- flex: 0 0 0;
-}
-
-.col-toc-hidden {
- display: none;
-}
-
-@media only screen and (min-width: 1000px) {
- .col-nav,
- .col-toc {
- flex: 0 0 21em;
- }
-}
-
-section.section {
- margin: 0 auto;
-}
-
-/*
- * sidebar *********************************************************************
- */
-
-.wrapper.right-open #sidebar-wrapper {
- width: 270px;
-}
-
-.wrapper.right-open .page-content {
- padding-right: 190px;
-}
-
-.col-nav,
-.col-toc {
- min-height: 100vh;
-}
-
-.col-nav {
-// background-color: $bg-sidebar;
-border-right: 1px solid #ddd;
-
-}
-
-.col-toc {
- margin-left: auto;
-}
-
-.sidebar {
- position: sticky;
- top: $top-navigation-height;
- overflow: auto;
- max-height: calc(100vh - #{$top-navigation-height});
- padding-bottom: 20px;
-}
-
-/*
- * global footer **************************************************************
- */
-
-footer {
- background: $white;
- border-top: 1px solid $light-grey-200;
- position: relative;
-}
-
-.top_footer {
- padding: 50px 0 35px;
-}
-
-.footer_links {
- list-style: none;
- padding: 0;
- li {
- margin-bottom: 10px;
- a {
- color: $black;
- font-size: 12px;
- line-height: 16px;
- }
- }
-}
-
-.footer_sub_nav {
- float: right;
- padding: 10px 30px 20px 0;
- ul {
- list-style: none;
- margin: 0;
- padding: 0;
- li {
- float: left;
- margin-left: 10px;
- padding-bottom: 6px;
- a {
- color: $white;
- font-size: 12px;
- }
- }
- }
-}
-
-.bottom_footer {
- clear: both;
- padding: 30px 0 20px;
- border-top: 1px solid $light-grey-200;
- float: left;
- width: 100%;
-}
-
-.footer-copyright {
- float: left;
-}
-
-.footer-copyright p {
- font-size: 12px;
- line-height: 17px;
- color: $light-grey-500;
- margin-bottom: 0;
- padding: 0 0 15px;
-}
-
-.footer_social_nav {
- float: right;
- padding: 0 15px 0 0;
-}
-
-.footer_social_nav ul {
- list-style: none;
- padding: 0;
- margin: 0;
-}
-
-.footer_social_nav ul li {
- float: left;
- position: relative;
- display: flex;
- justify-content: center;
- align-items: center;
-}
-
-.footer_social_nav ul li:before {
- color: $white;
- position: absolute;
-}
-
-.footer_social_nav ul li+li {
- margin-left: 10px;
-}
-
-.footer_social_nav ul li a {
- width: 32px;
- height: 32px;
- background-color: $light-grey-400;
- border-radius: 50px;
- color: $white;
- display: block;
- text-indent: 9999px;
- overflow: hidden;
-}
diff --git a/_scss/_mobile.scss b/_scss/_mobile.scss
deleted file mode 100755
index 950630a3dc..0000000000
--- a/_scss/_mobile.scss
+++ /dev/null
@@ -1,278 +0,0 @@
-/*
- * for rescaling **************************************************************
- */
-
-@media only screen
- and (min-width : 376px)
- and (max-width : 1150px) {
- .nav-primary,
- ul.primary.nav.navbar-nav {
- display: none;
- }
- .header {
- height: 55px;
- }
- .tabs li a {
- font-size: 13px;
- }
-
- h1,
- h2,
- h3 {
- margin-top: 10px;
- margin-bottom: 0;
- }
- h1 {
- font-size: 24px;
- line-height: 28px;
- }
- h2 {
- font-size: 20px;
- }
- h3 {
- font-size: 18px;
- }
- h4 {
- font-size: 16px;
- }
- .nav-secondary .search-form input[type=search] {
- min-width: auto;
- }
- .nav-container,
- .nav-secondary {
- overflow: hidden;
- }
- .nav-sidebar ul li li a {
- border-left: 0;
- font-size: 12px;
- margin-left: 0;
- }
- }
-
-@media only screen
- and (min-width : 376px)
- and (max-width : 900px) {
- .sidebar {
- position: fixed;
- top: 55px; // top-navigation bar (without breadcrumbs)
- width: 100%;
- z-index: 100;
- background-color: $bg-sidebar;
- }
- }
-
-
-/*
- * small displays mobile **********************************************************
- */
-
-/* Portrait and Landscape */
-@media only screen
- and (min-device-width: 320px)
- and (max-device-width: 670px) {
- .logo,
- .ctrl-right {
- display: none;///// CHECK THIS /////
- }
- .nav-container {
- overflow: visible;
- height: auto;
- }
- iframe {
- width: 100%;
- }
-}
-
-/* Portrait */
-@media only screen
- and (min-device-width: 320px)
- and (max-device-width: 667px)
- and (orientation: portrait) {
- h1,
- h2,
- h3 {
- margin-top: 10px;
- margin-bottom: 0;
- }
- h1 {
- font-size: 24px;
- line-height: 28px;
- }
- h2 {
- font-size: 20px;
- }
- h3 {
- font-size: 18px;
- }
- h4 {
- font-size: 16px;
- }
- .header {
- height: 100px;
- }
- .tabs {
- float: left;
- margin: 0;
- padding: 5px 0 0 17px;
- }
- .tabs li a {
- color: #fff;
- padding: 17px 6px 10px 4px;
- float: left;
- opacity: 0.7;
- font-size: 12px;
- }
- .content {
- padding: 65px 25px;
- }
- .sidebar {
- background-color: $bg-sidebar;
- top: 51px;
- left: 0;
- display: block;
- padding: 0;
- overflow-x: hidden;
- overflow-y: auto;
- position: fixed;
- width: 100%;
- }
- .search-form {
- display: block!important;
- }
- .top_footer {
- padding: 50px 0 35px;
- text-align: center;
- }
-}
-
-@media only screen
- and (min-device-width: 320px)
- and (max-device-width: 372px)
- and (orientation: portrait) {
- .tabs {
- display: -webkit-box;
- display: -moz-box;
- display: -ms-flexbox;
- display: -webkit-flex;
- display: flex;
- justify-content: space-between;
- width: 100%;
- padding: 5px 0 0 0;
- }
- .tabs li a {
- margin-left: 0;
- font-weight: normal;
- }
-
-}
-
-/* Landscape */
-@media only screen
- and (min-device-width: 320px)
- and (max-device-width: 667px)
- and (orientation: landscape) {
- h1,
- h2,
- h3 {
- margin-top: 10px;
- margin-bottom: 0;
- }
- h1 {
- font-size: 24px;
- line-height: 28px;
- }
- h2 {
- font-size: 20px;
- }
- h3 {
- font-size: 18px;
- }
- h4 {
- font-size: 16px;
- }
- .header {
- height: 100px;
- }
- .content {
- padding: 120px 20px;
- }
- .sidebar {
- background-color: $bg-sidebar;
- top: 55px; // top-navigation bar (without breadcrumbs)
- left: 0;
- display: block;
- padding: 0;
- overflow-x: hidden;
- overflow-y: auto;
- position: fixed;
- width: 100%;
- }
-}
-
-
-/*
- * medium displays mobile *****************************************************
- */
-
-
-@media only screen
- and (min-device-width: 768px)
- and (max-device-width: 1110px) {
- .logo {
- margin: 12px 10px 0 10px;
- width: 130px;
- }
- h1,
- h2,
- h3 {
- margin-top: 10px;
- margin-bottom: 0;
- }
- h1 {
- font-size: 24px;
- line-height: 28px;
- }
- h2 {
- font-size: 20px;
- }
- h3 {
- font-size: 18px;
- }
- h4 {
- font-size: 16px;
- }
- .toc-nav a {
- font-size: 11px;
- }
- .sidebar {
- background-color: $bg-sidebar;
- }
-}
-
-/* Landscape */
-@media only screen
- and (min-device-width: 768px)
- and (max-device-width: 1024px)
- and (orientation: landscape) {
- .ctrl-right {
- display: block;
- }
-
- .sidebar, .sidebar.affix {
- width: 270px;
- }
-}
-
-.navbar-toggle {
- display: block;
-}
-
-@media (min-width: 992px) {
- .navbar-toggle {
- display: none;
- }
-
- .nav-sidebar.collapse {
- display: block;
- }
-}
diff --git a/_scss/_navigation.scss b/_scss/_navigation.scss
deleted file mode 100755
index 7f82ae1f56..0000000000
--- a/_scss/_navigation.scss
+++ /dev/null
@@ -1,337 +0,0 @@
-/*
- * Primary navigation - top header *********************************************
- */
-.nav-container {
- height: 55px;
-}
-
-.sidebar-toggle {
- margin: 4px 0 0 0;
- float: right;
- padding: 16px 15px 0 0;
-}
-
-/*
- * Secondary Navigation *******************************************************
- */
-
-.nav-secondary {
- background-color: $bg-secondary;
- box-shadow: 0 1px 13px rgba(0, 0, 0, 0.24);
-}
-
-/*
- * Breadcrumbs ****************************************************************
- */
-.breadcrumb {
- background-color: $bg-sidebar-active;
- border-radius: 0;
- margin-bottom: 0;
- padding-left: 22px; // left-align with logo
- border-bottom: 0.1px solid rgba($primary-links, .5);
-
- a:not([href]) {
- cursor: default;
- }
-}
-
-/*
- * NAV SIDEBAR *****************************************************************
- */
-
-// Some links don't have 'href' attr, hence no mouse pointer
-.nav-sidebar li a {
- cursor: pointer;
- color: $light-grey-800;
-}
-
-.nav-sidebar>li>a {
- padding-right: 20px;
- padding-left: 20px;
-}
-
-.nav-sidebar>.active>a,
-.nav-sidebar>.active>a:focus,
-.nav-sidebar>.active>a:hover {
- color: $light-blue-600;
- background-color: $light-blue-500;
-}
-
-.nav-sidebar ul {
- list-style: none;
- padding: 0;
- text-align: left;
-
- li {
- display: block;
- }
-}
-
-.nav-sidebar .nav ul {
- padding: 0 0 0 15px;
-}
-
-.nav-sidebar ul li a:hover {
- opacity: 0.7;
- background: transparent;
-}
-
-.nav-sidebar ul li a,
-.nav-sidebar ul li a:focus {
- border-bottom: none;
- // border-left: 1px solid $light-grey-200;
-}
-
-.nav-sidebar .nav > li > a {
- padding-left: 22px; // left-padding to align with logo
- &.active {
- padding-left: 19px; // compensate for 1px -> 4px border-width
- }
- @include before-md-width {
- padding-right: 32px; // right-align with hamburger menu
- }
-}
-
-.nav-sidebar ul li a.active,
-.nav-sidebar.nav > li > a:focus {
- background: $bg-sidebar-active;
- border-left: 4px solid $light-blue-500;
- font-weight: 600;
- color: $light-blue-500;
-}
-
-.nav-sidebar ul li ul li a {
- font-size: 12px;
- margin-left: 8px;
-}
-
-.nav-sidebar .caret {
- float: right;
- margin-top: 10px;
-}
-
-/* pointer for collapsed sidebar list items */
-
-.collapsed
-{
- cursor:pointer;
-}
-
-/*
- * Table of contents menu *****************************************************
- */
-
-.toc-toggle {
- width: 25px;
- height: 25px;
- float: right;
-}
-
-.toc-nav ul {
- list-style: none;
- margin: 0;
- padding-left: 10px;
- line-height: 20px;
- li {
- padding: 2px 8px 2px 0;
- width: 100%;
- a {
- display: inline-block;
- font-size: 12px;
- padding: 2px 10px 2px 10px;
- color: $light-grey-500;
- }
- .slider{
- background-color: $light-grey-200;
- border: 1px solid $light-grey-200;
- }
- .slider:before{
- background-color: $light-grey-500;
- }
- }
-}
-
-.toc-nav li a.active {
- border-left: 4px solid $light-grey-500;
- font-weight: bold;
- color: $light-grey-500;
-}
-
-.toc-nav i.fa {
- font-size: 14px;
- margin: 0 8px 0 0;
- color: $light-grey-500;
-}
-
-div.side-toc-title {
- font-size: 12px;
- font-weight: bold;
- margin: 11px 0 10px 13px;
- color: $light-grey-500;
-}
-
-.edit {
- margin: 10px 0 20px 15px;
-}
-
-/*
- * Toggle Switches *************************************************************
- */
-
-.toggle-mode {
- float: left;
- padding: 0 0 0 10px;
- width: 100%;
- .icon {
- width: 25px;
- float: left;
- font-size: 1rem;
- }
-}
-
-
-.toggle-switch {
- float: left;
- height: 40px;
- width: 60px;
- padding: 3px 7px 0 2px;
-}
-
-.switch {
- position: relative;
- display: inline-block;
- width: 47px;
- height: 19px;
-}
-
-.switch input {
- display: none;
-}
-
-.slider {
- position: absolute;
- cursor: pointer;
- top: 0;
- left: 0;
- right: 0;
- bottom: 0;
- background-color: $slider-bg;
- border: 1px solid $light-blue-200;
-}
-
-.slider:before {
- background-color: $slider-btn;
- position: absolute;
- content: "";
- height: 15px;
- width: 15px;
- left: 2px;
- bottom: 1px;
-}
-
-input:focus+.slider {
- box-shadow: 0 0 1px $slider-btn;
-}
-
-input:checked+.slider:before {
- -webkit-transform: translateX(26px);
- transform: translateX(26px);
-}
-
-.slider.round {
- border-radius: 34px;
-}
-
-.slider.round:before {
- border-radius: 50%;
-}
-
-
-/*
- * Tabs ************************************************************************
- */
-
-.navbar-nav > li > a {
- border-left: 4px solid rgba($white, 0.0);
-}
-.navbar-nav > li.active > a {
- border-left: 4px solid rgba($white, 0.75);
-}
-
-@include md-width {
- .landing .navbar-nav > li > a {
- padding-top: 17px;
- padding-bottom: 9px;
- }
- .navbar-nav > li > a {
- color: $white;
- line-height: 25px;
- padding-top: 14px;
- padding-bottom: 12px;
- font-weight: 600;
-
- &:hover {
- background-color: rgba(0, 0, 0, 0.17);
- border-bottom: 4px solid $white;
- }
- }
- .navbar-nav > li.active > a {
- cursor: default;
- border-left: none;
- border-bottom: 4px solid $white;
- }
-}
-
-div.feedback-links {
- margin: 15px 0 10px 0;
-}
-
-div.metadata-items {
- margin: 15px 0 10px 0;
- ul {
- list-style: none;
- margin: 0;
- padding-left: 20px;
- line-height: 20px;
- li {
- padding: 2px 8px 2px 0;
- width: 100%;
- font-size: 12px;
- a {
- padding: 0;
- }
- }
- }
-}
-
-div.keywords-items {
- padding-left: 20px;
- font-size: 12px;
- a {
- display: inline-block;
- margin-right: 8px;
- i.fa {
- margin: 0;
- }
- }
-}
-
-/*
- * Controls ********************************************************************
- */
-
-.ctrl-left {
- float: left;
- width: 20px;
- margin: 3px 0 0 0;
-}
-
-.ctrl-right {
- float: right;
- padding: 5px 0;
-}
-
-.ctrl-right .btn-group {
- float: left;
- margin: 2px 0 0;
-}
diff --git a/_scss/_night-mode.scss b/_scss/_night-mode.scss
deleted file mode 100755
index f68c6f229d..0000000000
--- a/_scss/_night-mode.scss
+++ /dev/null
@@ -1,282 +0,0 @@
-html.night {
- color-scheme: dark;
-
- $icons: rocket, download-docker, guides, language-guides, whats-new, manuals, reference;
-
- body {
- background-color: $bg-body-night;
- color: $body-text-night;
-
- &.landing {
- background-color: $bg-body-landing-night;
- .header > .container {
- background-color: $bg-header-night;
- }
- .card, .cardlet {
- color: inherit;
- background-color: $bg-card-night;
- &.rocket {
- background-image: url(/assets/images/rocket-dark.svg)
- }
- &.download-docker {
- background-image: url(/assets/images/download-docker-dark.svg)
- }
- &.guides {
- background-image: url(/assets/images/guides-dark.svg)
- }
- &.language-guides {
- background-image: url(/assets/images/language-guides-dark.svg)
- }
- &.manuals {
- background-image: url(/assets/images/manuals-dark.svg)
- }
- &.reference {
- background-image: url(/assets/images/reference-dark.svg)
- }
- }
- footer {
- background-color: $bg-footer-landing-night;
- }
- }
- }
-a {
- color: $dark-blue-600;
-}
- .rating-nero-value,
- .reading-time,
- .release-date {
- color: $body-text-night !important;
- }
-
- h1,h2,h3,h4,h5,h6,
- div#side-toc-title {
- color: $white;
- }
- .button {
- color: $white;
- }
- a:not(.btn):not(.button) {
- //color: $primary-links-night;
- }
- .header {
- background-color: $bg-header-night;
- color: $white;
- }
- hr {
- border-top: 1px solid #4f6071;
- }
- .nav-secondary {
- background-color: $bg-header-night;
- }
- .breadcrumb {
- background-color: $dark-grey-100;
- border-bottom: 0.1px solid $dark-grey-700;
- }
- .sidebar,
- .col-nav {
- background-color: $bg-sidebar-night;
- border: none;
- color: $dark-grey-700;
- }
- .nav-sidebar li a {
- cursor: pointer;
- color: $dark-grey-700;
- }
- .toc-nav ul li a {
- color: $dark-grey-700;
- }
- .nav-sidebar ul li a.active,
- .nav-sidebar.nav > li > a:focus,
- .toc-nav li a.active {
- background: $dark-palette-background;
- //border-left: 4px solid $dark-blue-800;
- color: $white;
- }
- div.side-toc-title {
- color: $dark-grey-700;
- }
- .navbar-nav > li.active > a {
- border-color: $dark-blue-600;
- border-bottom: 4px solid $white;
- }
- .slider {
- background-color: #344658;
- border: 1px solid #192837;
- }
- table {
- border: 1px solid #1b1a1a;
- color: #cbdbe6;
- }
- table>tbody>tr:nth-of-type(even) {
- background-color: #1f3341;
- }
- thead {
- background: #2b4252;
- }
- pre {
- color: #f3f3f3;
- background-color: #0a121b !important;
- border: 1px solid $black;
- }
- code {
- color: $dark-grey-700 !important;
- background: #0a121b !important;
- }
- .nav-secondary .dropdown-btn {
- color: #d0e8ff;
- }
- .outline-btn {
- background: $bg-sidebar-night;
- border: 1px solid $body-text;
-
- }
- a.button.outline-btn {
- color: $primary-links-night;
- }
- a.glossary,
- .toc-nav i.fa {
- color: $body-text-night;
- }
- #autocompleteResults {
- background: $bg-search-results-night;
- border: 1px solid $black;
- //color: $white;
- }
- .autocompleteResult {
- &.selected {
- background-color: #1f262e;
- }
- li {
- color: #b4c3d2;
- }
- span {
- color: #b7a4de;
- }
- }
-
- /* for google results styles - forgive us css gods */
- .gsc-control-cse .gsc-webResult.gsc-result, .gsc-results .gsc-imageResult {
- border-color: #192837!important;
- background-color: #192837!important;
- }
- .gsc-webResult.gsc-result:hover, .gsc-imageResult:hover {
- border-color: #25374a!important;
- background-color: #192837!important;
- }
- a.gs-title {
- color: $dark-grey-700 !important;
- text-decoration: none;
- }
- .gs-webResult .gs-snippet, .gs-imageResult .gs-snippet, .gs-fileFormatType {
- color: #a8b0b7!important;
- }
- .gs-webResult.gs-result a.gs-title:link, .gs-webResult.gs-result a.gs-title:link b, .gs-imageResult a.gs-title:link, .gs-imageResult a.gs-title:link b {
- color: $dark-blue-700!important;
- }
- .component {
- background: $bg-component-night;
- img {
- opacity: 1;
- filter: grayscale(100%) brightness(2);
- }
- }
- .transparent-btn {
- background-color: rgb(0, 135, 200);
- box-shadow: 0 1px 0 0 rgba(0, 0, 0, 0.1);
- border: 1px solid rgba(0, 0, 0, 0.1);
- text-shadow: 0 1px rgba(0, 0, 0, 0.2);
- }
- .primary-btn{
- background: $dark-blue-100;
- }
- .footer {
- background-color: $bg-footer-night;
- border-top: 1px solid rgb(31, 52, 66);
- }
- .footer_links li a {
- color: $white;
- }
- .bottom_footer {
- border-top: 1px solid rgb(78, 93, 106);
- }
- .footer_social_nav ul li a {
- background-color: #2f2f2f;
- }
- .footer_sub_nav ul li a {
- color: $white;
- }
- .footer-copyright p {
- color: $white;
- }
-
- /* syntax highlighting */
- .highlight {
- .nt {
- color: #FBB552;
- }
- .k {
- color: #EEA3A5;
- }
- }
-
- /* apply to images with garbled text */
- img.white-bg {
- background-color: white;
- }
-
- /* apply to images that support being inverted */
- img.invertible {
- filter: invert(100%) hue-rotate(180deg);
- }
-
- /* accordion */
- .panel {
- color: $body-text-night;
- background-color: #24394c;
- }
- .panel-default {
- border-color: #374656;
- >.panel-heading {
- color: #c0c3c4;
- background-color: $bg-sidebar-night;
- border-color: #2f4050;
- }
- }
- .panel-body {
- background: rgb(35, 54, 72);
- color: #bcbfc3;
- }
-
- /* modals */
- .modal-content {
- background-color: $bg-sidebar-night;
- border-left: 4px solid $primary-links;
- }
-
- /* tabs */
- .nav-tabs {
- border-bottom: 1px solid #4f6071;
- color: $dark-grey-700;
- }
- .nav-tabs>li>a {
- color: $dark-grey-700;
- }
- .nav-tabs>li.active>a, .nav-tabs>li.active>a:focus, .nav-tabs>li.active>a:hover {
- color: $white;
- background-color: $dark-grey-200;
- border: 1px solid transparent;
- }
- .popover {
- color: $black;
- }
- .pagination>li>a, .pagination>li>span {
- background-color: #0f1c2a!important;
- border: 1px solid #0f1c2a!important;
- }
- .pagination>.active>a {
- background: #000!important;
- color: $white!important;
- }
-}
-
-
diff --git a/_scss/_notes.scss b/_scss/_notes.scss
deleted file mode 100644
index d34dea6648..0000000000
--- a/_scss/_notes.scss
+++ /dev/null
@@ -1,206 +0,0 @@
-//noinspection CssNoGenericFontName
-
-/*
-
-These rules control the display of notes/notifications/alerts. They can be used like so:
-
-> This is a paid feature
->
-> Docker Hub Vulnerability Scanning is available for developers subscribed to a Pro or a Team plan. For more information about the pricing plans, see [Docker Pricing](https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade)
-{: .restricted }
-
-(The first line is always treated as a header, unless it's the only line)
-
-The available classes are:
-
-.important: Yellow
-.warning: Red/orange
-.tip: Green
-.restricted: Purple, used to indicate features that require paid plans
-[no class]: Blue, the default
-
-*/
-
-@mixin notification($bg-color, $header-color, $body-text-color, $icon) {
- background-color: $bg-color;
- font-size: unset; // override bootstrap font-size for blockquotes
-
- // The first child will generally be a header (e.g. "Note" or "This is an experimental feature"),
- // but we have some notes that don't have headers; if there's only one child of the note,
- // assume it's not a header
- > p:first-child:not(:only-child) {
- color: $header-color;
- font-weight: 700;
- margin-top: 0;
-
- // https://fontawesome.com/docs/web/setup/upgrade/pseudo-elements
- &::before {
- text-rendering: auto;
- -webkit-font-smoothing: antialiased;
- font: var(--fa-font-solid);
- content: "#{$icon} \00a0";
- }
- }
-
- > p:only-child, > p:not(:first-child) {
- color: $body-text-color;
- }
-
- a {
- text-decoration: underline;
- }
-}
-
-
-
-blockquote {
- html.night & {
- // DARK THEME
-
- &:not(.important):not(.warning):not(.restricted):not(.experimental):not(.tip) {
- @include notification(
- $bg-color: $dark-blue-200,
- $header-color: $white,
- $body-text-color: $white,
- $icon: "\f06a"
- );
- a {
- color: $dark-blue-800;
- };
- }
-
- &.important {
- @include notification(
- $bg-color: $dark-amber-300,
- $header-color: $white,
- $body-text-color: $white,
- $icon: "\f06a"
- );
- a {
- color: $dark-blue-200;
- }
- }
-
- &.warning {
- @include notification(
- $bg-color: $dark-red-200,
- $header-color: $white,
- $body-text-color: $white,
- $icon: "\f06a"
- );
- }
-
- &.restricted {
- @include notification(
- $bg-color: $dark-viole-200,
- $header-color: $white,
- $body-text-color: $white,
- $icon: "\f135"
- );
- }
-
- &.experimental {
- @include notification(
- $bg-color: $dark-blue-200,
- $header-color: $white,
- $body-text-color: $white,
- $icon: "\f492"
- );
- }
-
- &.tip {
- @include notification(
- $bg-color: $dark-green-200,
- $header-color: $white,
- $body-text-color: $white,
- $icon: "\f164"
- );
- }
- }
-
- html:not(.night) & {
- // LIGHT THEME
-
- &:not(.important):not(.warning):not(.restricted):not(.experimental):not(.tip) {
- @include notification(
- $bg-color: $light-blue-100,
- $header-color: $light-blue-600,
- $body-text-color: inherit,
- $icon: "\f05a"
- );
- }
-
- &.important {
- @include notification(
- $bg-color: $light-amber-100,
- $header-color: $dark-amber-300,
- $body-text-color: inherit,
- $icon: "\f06a"
- );
- }
-
- &.warning {
- @include notification(
- $bg-color: $light-red-300,
- $header-color: $light-red-700,
- $body-text-color: inherit,
- $icon: "\f06a"
- );
- }
-
- &.restricted {
- @include notification(
- $bg-color: $light-viole-200,
- $header-color: $light-viole-600,
- $body-text-color: inherit,
- $icon: "\f135"
- );
- }
-
- &.experimental {
- @include notification(
- $bg-color: $light-blue-100,
- $header-color: $light-blue-500,
- $body-text-color: inherit,
- $icon: "\f492"
- );
- }
-
- &.tip {
- @include notification(
- $bg-color: $light-green-200,
- $header-color: $light-green-600,
- $body-text-color: inherit,
- $icon: "\f164"
- )
- }
- }
-}
-
-/* For Bootstrap badges */
-span {
- &.badge {
- border-radius: .25rem;
- color: #fff;
- display: inline-block;
- font-size: 75%;
- font-weight: bold;
- line-height: 1;
- padding: .25em .4em;
- text-align: center;
- vertical-align: baseline;
- white-space: nowrap;
-
- &.badge-info {
- background-color: $note-color;
- }
-
- &.badge-danger {
- background-color: $warning-color;
- }
-
- &.badge-warning {
- background-color: $important-color;
- }
- }
-}
diff --git a/_scss/_overrides.scss b/_scss/_overrides.scss
deleted file mode 100755
index 215e79c6e4..0000000000
--- a/_scss/_overrides.scss
+++ /dev/null
@@ -1,158 +0,0 @@
-/*
- * Bootstrap Overrides *********************************************************
- */
-
-.navbar-toggle {
- padding: 0;
- margin: 0;
-
- .icon-bar {
- background-color: #fff !important;
- }
-}
-
-.navbar-collapse,
-.navbar-form {
- border-color: transparent;
-}
-
-.nav>li>a:focus,
-.nav>li>a:hover {
- background-color: transparent;
-}
-
-.dropdown-menu>li>a {
- font-size: 13.5px;
- line-height: 16px;
- color: $light-blue-400;
- padding: 5px 15px;
- display: block;
-}
-
-.btn {
- font-weight: bold;
-}
-
-.btn-primary, .btn-secondary {
- padding: 10px 15px 6px;
- font-family: $buttons;
-}
-.btn-primary {
- background-color: $light-blue-500;
- border: 1px solid rgba(0, 0, 0, 0.1);
-
- &:hover {
- opacity: 0.8;
-
- // override default bootstrap behaviour
- background-color: $light-blue-500;
- border: 1px solid rgba(0, 0, 0, 0.1);
- }
-}
-
-.btn-default:hover {
- color: #fff!important;
- background-color: transparent!important;
- border-color: none!important;
- box-shadow: none!important;
- opacity: .8;
-}
-
-.btn-group.open .dropdown-toggle {
- -webkit-box-shadow: inset 0 3px 5px rgba(0, 0, 0, .125);
- background: transparent;
- color: #fff;
- box-shadow: none;
-}
-
-.btn-default:focus,
-.btn-default.active,
-.btn-default:active,
-.open>.dropdown-toggle.btn-default:focus,
-.open>.dropdown-toggle.btn-default:hover {
- color: #fff!important;
- background-color: transparent!important;
- border-color: transparent !important;
- box-shadow: none!important
-}
-
-.nav .open>a,
-.nav .open>a:focus,
-.nav .open>a:hover {
- background-color: transparent;
- border-color: $primary-links;
-}
-
-.dropdown-menu>li>a:focus,
-.dropdown-menu>li>a:hover {
- color: #ffffff;
- background-color: $light-blue-700;
-}
-
-/*
- * Bootstrap expand/collapse accordions ****************************************
- */
-
-.panel-heading .chevron::after {
- content: "\f0d8";
-}
-
-.panel-heading.collapsed .chevron::after {
- content: "\f0d7";
-}
-
-.panel-heading:hover{
- background-color: #fafdfe;
-}
-
-/*
- * override google results +++++++++++++++++++++++++++++++++++++++++++++++++++++
- */
-.gs-webResult .gs-snippet, .gs-imageResult .gs-snippet, .gs-fileFormatType {
- color: $light-blue-700!important;
- line-height: 23px!important;
-}
-.gsc-webResult .gsc-result {
- padding: 20px 0 20px 20px!important;
-}
-
-a.gs-title {
- color: $light-blue-500!important;
- text-decoration: none;
-}
-
-.gs-webResult.gs-result a.gs-title:visited, .gs-webResult.gs-result a.gs-title:visited b, .gs-imageResult a.gs-title:visited, .gs-imageResult a.gs-title:visited b {
- color: $light-red-400!important;
-}
-.gs-webResult div.gs-visibleUrl, .gs-imageResult div.gs-visibleUrl {
- color: $light-grey-600!important;
-}
-
-.gs-webResult .gs-snippet, .gs-imageResult .gs-snippet, .gs-fileFormatType {
- font-size: 14px!important;
-}
-
-.gsc-tabHeader.gsc-tabhActive, .gsc-tabsArea {
- border-color: #f7f7f761 !important;
- background: transparent;
-}
-.gsc-tabHeader.gsc-tabActive, .gsc-refinementHeader.gscrefinementActive{
- color: $dark-grey-700!important;
-}
-
-.gsc-results .gsc-cursor-box .gsc-cursor-page{
- color: $black!important;
-}
-
-input.gsc-search-button, input.gsc-search-button:hover, input.gsc-search-button:focus {
- display: none!important;
-}
-
-.cse .gsc-search-button input.gsc-search-button-v2,
-input.gsc-search-button-v2 {
- width: 13px;
- height: 13px;
- padding: 6px 27px;
- min-width: 13px;
- margin-top: 2px;
-}
diff --git a/_scss/_perldoc.scss b/_scss/_perldoc.scss
deleted file mode 100755
index c35e3ad525..0000000000
--- a/_scss/_perldoc.scss
+++ /dev/null
@@ -1,88 +0,0 @@
-/*
-.highlight .hll { background-color: #ffffcc }
-.highlight { background: #eeeedd } */
-.highlight .c { color: #3BA08D } /* Comment */
-.highlight .err { color: #B72132 } /* Error */
-.highlight .k { color: #8B008B } /* Keyword */
-.highlight .ch { color: #3BA08D } /* Comment.Hashbang */
-.highlight .cm { color: #3BA08D } /* Comment.Multiline */
-.highlight .cp { color: #1e889b } /* Comment.Preproc */
-.highlight .cpf { color: #3BA08D } /* Comment.PreprocFile */
-.highlight .c1 { color: #3BA08D } /* Comment.Single */
-.highlight .cs { color: #8B008B } /* Comment.Special */
-.highlight .gd { color: #B72132 } /* Generic.Deleted */
-.highlight .ge { font-style: italic } /* Generic.Emph */
-.highlight .gr { color: #B72132 } /* Generic.Error */
-.highlight .gh { color: #9860FF } /* Generic.Heading */
-.highlight .gi { color: #00aa00 } /* Generic.Inserted */
-.highlight .go { color: #888888 } /* Generic.Output */
-.highlight .gp { color: #555555 } /* Generic.Prompt */
-
-// Prevent selecting comments, command-output and command-prompt in shell
-// examples that use the "console" lexer/highlighter to allow easier copying.
-// See https://github.com/rouge-ruby/rouge/issues/1023
-.language-console .highlight .c,
-.language-console .highlight .go,
-.language-console .highlight .gp
-{
- -webkit-user-select: none;
- -moz-user-select: none;
- -ms-user-select: none;
- user-select: none
-}
-
-// Show a "text" cursor for the prompt. Even though the prompt itself is not
-// selectable, make it appear as if it is, so that users don't get confused
-// when they try to select an example for copying.
-.language-console .highlight .gp {
- cursor: text;
-}
-
-.highlight .gs {} /* Generic.Strong */
-.highlight .gu { color: #800080 } /* Generic.Subheading */
-.highlight .gt { color: #B72132 } /* Generic.Traceback */
-.highlight .kc { color: #8B008B } /* Keyword.Constant */
-.highlight .kd { color: #8B008B } /* Keyword.Declaration */
-.highlight .kn { color: #8B008B } /* Keyword.Namespace */
-.highlight .kp { color: #8B008B } /* Keyword.Pseudo */
-.highlight .kr { color: #8B008B } /* Keyword.Reserved */
-.highlight .kt { color: #1C90ED } /* Keyword.Type */
-.highlight .m { color: #B452CD } /* Literal.Number */
-.highlight .s { color: #E25D68 } /* Literal.String */
-.highlight .na { color: #658b00 } /* Name.Attribute */
-.highlight .nb { color: #658b00 } /* Name.Builtin */
-.highlight .nc { color: #88D5C0 } /* Name.Class */
-.highlight .no { color: #1C90ED } /* Name.Constant */
-.highlight .nd { color: #707a7c } /* Name.Decorator */
-.highlight .ne { color: #88D5C0 } /* Name.Exception */
-/*.highlight .nf { color: #88D5C0 } Name.Function */
-.highlight .nn { color: #88D5C0 } /* Name.Namespace */
-.highlight .nt { color: #8B008B } /* Name.Tag */
-.highlight .nv { color: #1C90ED } /* Name.Variable */
-.highlight .ow { color: #8B008B } /* Operator.Word */
-.highlight .w { color: #bbbbbb } /* Text.Whitespace */
-.highlight .mb { color: #B452CD } /* Literal.Number.Bin */
-.highlight .mf { color: #B452CD } /* Literal.Number.Float */
-.highlight .mh { color: #B452CD } /* Literal.Number.Hex */
-.highlight .mi { color: #B452CD } /* Literal.Number.Integer */
-.highlight .mo { color: #B452CD } /* Literal.Number.Oct */
-.highlight .sa { color: #E25D68 } /* Literal.String.Affix */
-.highlight .sb { color: #E25D68 } /* Literal.String.Backtick */
-.highlight .sc { color: #E25D68 } /* Literal.String.Char */
-.highlight .dl { color: #E25D68 } /* Literal.String.Delimiter */
-.highlight .sd { color: #E25D68 } /* Literal.String.Doc */
-.highlight .s2 { color: #E25D68 } /* Literal.String.Double */
-.highlight .se { color: #E25D68 } /* Literal.String.Escape */
-.highlight .sh { color: #1c7e71 } /* Literal.String.Heredoc */
-.highlight .si { color: #E25D68 } /* Literal.String.Interpol */
-.highlight .sx { color: #cb6c20 } /* Literal.String.Other */
-.highlight .sr { color: #1c7e71 } /* Literal.String.Regex */
-.highlight .s1 { color: #E25D68 } /* Literal.String.Single */
-.highlight .ss { color: #E25D68 } /* Literal.String.Symbol */
-.highlight .bp { color: #658b00 } /* Name.Builtin.Pseudo */
-.highlight .fm { color: #88D5C0 } /* Name.Function.Magic */
-.highlight .vc { color: #1C90ED } /* Name.Variable.Class */
-.highlight .vg { color: #1C90ED } /* Name.Variable.Global */
-.highlight .vi { color: #1C90ED } /* Name.Variable.Instance */
-.highlight .vm { color: #1C90ED } /* Name.Variable.Magic */
-.highlight .il { color: #B452CD } /* Literal.Number.Integer.Long */
diff --git a/_scss/_typography.scss b/_scss/_typography.scss
deleted file mode 100755
index dc48c3b680..0000000000
--- a/_scss/_typography.scss
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * Fonts **********************************************************************
- */
-
-@font-face {
- font-family: 'Geomanist Book';
- src: url("../assets/fonts/geomanist/hinted-Geomanist-Book.eot");
- src: url("../assets/fonts/geomanist/hinted-Geomanist-Book.eot?#iefix") format("embedded-opentype"), url("../assets/fonts/geomanist/hinted-Geomanist-Book.woff2") format("woff2"), url("../assets/fonts/geomanist/hinted-Geomanist-Book.woff") format("woff"), url("../assets/fonts/geomanist/hinted-Geomanist-Book.ttf") format("truetype"), url("../assets/fonts/geomanist/hinted-Geomanist-Book.svg#Geomanist-Book") format("svg");
- font-weight: normal;
- font-style: normal;
- font-display: swap;
-}
-
-@font-face {
- font-family: 'Geomanist Regular';
- src: url("../assets/fonts/geomanist/hinted-Geomanist-Regular.eot");
- src: url("../assets/fonts/geomanist/hinted-Geomanist-Regular.eot?#iefix") format("embedded-opentype"), url("../assets/fonts/geomanist/hinted-Geomanist-Regular.woff2") format("woff2"), url("../assets/fonts/geomanist/hinted-Geomanist-Regular.woff") format("woff"), url("../assets/fonts/geomanist/hinted-Geomanist-Regular.ttf") format("truetype"), url("../assets/fonts/geomanist/hinted-Geomanist-Book.svg#Geomanist-Regular") format("svg");
- font-weight: normal;
- font-style: normal;
- font-display: swap;
-}
-
-/*
- * inlining the style from https://fonts.googleapis.com/css?family=Open+Sans&display=swap
- *
- * We're only including the "latin" glyphs. While including @font-faces for more
- * glyphs would not cause the fonts to be loaded, it would make the stylesheet
- * itself larger, and we don't need those glyhps for our purpose as the website
- * is written in US-English; https://stackoverflow.com/a/14897846/1811501
- */
-
-/* latin */
-/*@font-face {
- font-family: 'Open Sans';
- font-style: normal;
- font-weight: 400;
- font-display: fallback;
- src: local('Open Sans Regular'), local('OpenSans-Regular'), url(https://fonts.gstatic.com/s/opensans/v18/mem8YaGs126MiZpBA-UFVZ0bf8pkAg.woff2) format('woff2');
- unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-h1,h2,h3,h4,h5,h6 {
- font-family: $headings;
- clear: both;
- line-height: 26px;
- margin-top: 30px;
- margin-bottom: 0;
- font-weight: 600;
-}
-
-h1 {
- font-size: 36px;
- line-height: 48px;
-}
-
-h2 {
- font-size: 28px;
- line-height: 38px;
-}
-
-h3 {
- font-size: 22px;
-}
-
-h4 {
- font-size: 18px;
-}
-
-h5 {
- font-size: 16px;
-}
-
-h6 {
- color: #82949e;
- font-size: 14px;
-}
-
-dd, dt {
- line-height: 25px;
-}
-
-ol, ul {
- padding-left: 25px;
-}
-
-
-/* latin */
-@font-face {
- font-family: 'Roboto';
- font-style: normal;
- font-weight: 500;
- font-display: swap;
- src: url(https://fonts.gstatic.com/s/roboto/v30/KFOlCnqEu92Fr1MmEU9fBBc4.woff2) format('woff2');
- unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-/* latin */
-@font-face {
- font-family: 'Roboto';
- font-style: normal;
- font-weight: 400;
- font-display: swap;
- src: url(https://fonts.gstatic.com/s/roboto/v30/KFOmCnqEu92Fr1Mu4mxK.woff2) format('woff2');
- unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-/* latin */
-@font-face {
- font-family: 'Roboto Mono';
- font-style: normal;
- font-weight: 400;
- font-display: swap;
- src: url(https://fonts.gstatic.com/s/robotomono/v22/L0xTDF4xlVMF-BfR8bXMIhJHg45mwgGEFl0_3vrtSM1J-gEPT5Ese6hmHSh0mQ.woff2) format('woff2');
- unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-html, body {
- font-family: 'Roboto', sans-serif;
- font-size: 14px;
-}
-
-h1, .h1 {
- font-size: 2.5rem;
- font-weight: 500;
- line-height: 1.167;
-}
-
-h2, .h2 {
- font-size: 2rem;
- font-weight: 500;
- line-height: 1.2;
-}
-
-h3, .h3 {
- font-size: 1.5rem;
- font-weight: 500;
- line-height: 1.167;
-}
-
-h4, .h4 {
- font-size: 1.286rem;
- font-weight: 500;
- line-height: 1.235;
-}
-
-.subtitle1 {
- font-size: 1.143rem;
- font-weight: 500;
- line-height: 1.75;
-}
-
-p, .body1 {
- font-size: 1rem;
- line-height: 1.5;
-}
-
-p {
- margin: 0 0 16px;
-}
-
-.body2 {
- font-size: 0.86rem;
- line-height: 1.43;
-}
-
-code, pre {
- font-size: 1rem;
- font-family: 'Roboto Mono', monospace;
-}
-
-.overline {
- font-size: 0.72rem;
- font-weight: 500;
- line-height: 2.66;
- text-transform: uppercase;
-}
-
-.inline-code {
- font-size: 1rem;
- font-family: 'Roboto Mono', monospace;
- background-color: white; /* black if dark mode */
- border: 1px solid #E1E2E6; /* grey.200 */
- padding: 0.2em 0.4em;
- border-radius: 4px;
-}
-
-.code-block {
- font-size: 1rem;
- font-family: 'Roboto Mono', monospace;
- background-color: white; /* black if dark mode */
- border: 1px solid #E1E2E6; /* grey.200 */
- padding: 8px;
- border-radius: 4px;
- display: block;
-}
\ No newline at end of file
diff --git a/_scss/_upgrade-cta.scss b/_scss/_upgrade-cta.scss
deleted file mode 100644
index 548ca30448..0000000000
--- a/_scss/_upgrade-cta.scss
+++ /dev/null
@@ -1,27 +0,0 @@
-.docker-upgrade-cta {
- html.night & {
- background-color: change-color($light-amber-100, $alpha: 0.3);
- border: 1px solid $light-amber-100;
- p, .docker-upgrade-cta__heading { color: $white; }
- }
-
- html:not(.night) & {
- background-color: $light-amber-100;
- border: 1px solid $light-amber-200;
- p, .docker-upgrade-cta__heading { color: inherit; }
- }
-
- padding: 16px 25px;
- margin: 0 0 20px;
-
- border-radius: 3px;
-
- .docker-upgrade-cta__heading {
- font-weight: bold;
- font-size: 16px;
-
- font-family: $headings;
-
- margin-top: 0;
- }
-}
diff --git a/_scss/_utilities.scss b/_scss/_utilities.scss
deleted file mode 100755
index e3c8b6b90a..0000000000
--- a/_scss/_utilities.scss
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * utilities *******************************************************************
- */
-
-.archive-panel {
- padding: 10px 5px;
- height: 100px;
- width: 100%;
- display: none;
-}
-
-.reading-time {
- font-size: 12px;
- color: rgba(13, 86, 125, 0.55);
-}
-
-.release-date {
- font-size: 12px;
- color: rgba(13, 86, 125, 0.55);
-}
-
-.github-issue {
- font-size: 110%;
- margin-right: 5px;
-}
-
-.break {
- margin-bottom: 20px!important;
-}
-
-/*
- * tables **********************************************************************
- */
-
-table {
- border: 1px solid rgba(204, 204, 204, 0.29);
- margin: 0 0 15px 0;
- width: 100%;
-}
-
-table>tbody>tr:nth-of-type(even) {
- background-color: #f7f7f7;
-}
-
-td {
- padding: 10px;
-}
-
-th,
-td.th {
- font-weight: bold;
- padding: 7px 10px 7px 10px;
- text-align: left;
-}
-
-thead {
- background: $table-head;
-}
-
-/* give tables some breathing room */
-.content table {
- margin-top: 20px;
- margin-bottom: 20px;
-}
-
-i.fa.fa-indent,
-i.fa.fa-outdent {
- color: $white;
- padding: 16px 15px 0 0;
- font-size: 1.5rem;
-}
-
-/* Inline graphics and icons (like the whale menu icon in d4mac, d4win) */
-img.inline {
- display: inline;
-}
-
-/*
- * Search **********************************************************************
- */
-.search-form {
- float: left;
- margin: 5px 8px 0 0;
- & input[type=text] {
- background: rgba(0, 0, 0, 0.17) url("/assets/images/search.png") no-repeat 10px 9px;
- border: 0;
- color: $light-blue-700;
- border-radius: 0;
- margin: 0;
- transition: all 0.2s ease;
- width: 230px;
- }
-}
-
-.nav-secondary input[type=search]
-{
- background: rgba(0, 0, 0, 0.17) url("/assets/images/search.png") no-repeat 10px 9px;
- border: 0;
- box-shadow: none;
- color: #fff;
- border-radius: 0;
- transition: all 0.2s ease;
- padding: 0 0 0 35px;
- width: 100%;
-}
-
-.search-form input[type=text]:focus {
- background: #fff;
- box-shadow: 0;
-}
-
-input[type=text] {
- margin: 0;
- background: rgba(0, 0, 0, 0.17) url(/assets/images/search.png) no-repeat 10px 9px;
- border: 1px solid transparent;
- box-shadow: none;
- transition: all 0.2s ease;
-}
-
-.nav-secondary .search-form input[type=search]:focus {
- background: rgba(255, 255, 255, 0.17) url(/assets/images/search.png) no-repeat 10px 9px;
-}
-
-.search-form input[type=search]::placeholder
-{
- color: #fff;
- opacity: 1;
-}
-
-/*
- * autocompleteResults *********************************************************
- */
-
-#autocompleteResults {
- display: none; /* toggled through javascript */
-
- background: #E6F5FD;
- border: 1px solid #eee;
- box-shadow: 1px 2px 2px rgba(0, 0, 0, 0.28);
- margin: 10px 0 0 0;
- position: absolute;
- width: 600px;
- z-index: 9999;
-}
-
-.autocompleteResult {
- border-bottom: 1px solid rgba(203, 205, 209, 0.4);
- cursor: pointer;
- padding: 15px;
- &.selected {
- background-color: #f5f5f5;
- }
-
- ul {
- list-style: none;
- margin: 0 5px 0 5px;
- padding-inline-start: 0;
-
- @include before-lg-width {
- padding: 0;
- }
- }
-
- li {
- border: 0;
- margin: 0;
- max-width: 100%;
- padding: 5px 0 7px 0;
- line-height: normal;
- }
-
- .title {
- font-weight: bold;
- }
-
- .keywords {
- font-size: 12px;
- .glyphicon {
- padding-right: 10px
- }
- }
-
- span {
- background: transparent;
- color: #518cad;
- }
-}
-
-.modal-dialog {
- .modal-header, .modal-footer {
- border: none;
- }
- .modal-header .close {
- display: none;
- }
- .btn-primary {
- background-color: $primary-links;
- }
- .btn-secondary {
- background: transparent;
- border-color: $primary-links;
- &:hover {
- color: inherit;
- }
- }
-}
-
-@media print {
- .col-nav,
- .col-toc,
- .footer,
- .glyphicon-tags,
- {
- display: none !important;
- }
-}
-
-/*
- * lists **********************************************************************
- */
-
-ol li ol li {
- list-style-type: lower-alpha;
-}
-
-ol li ol li ol li {
- list-style-type: lower-roman;
-}
\ No newline at end of file
diff --git a/_scss/_variables.scss b/_scss/_variables.scss
deleted file mode 100755
index 28daf2c250..0000000000
--- a/_scss/_variables.scss
+++ /dev/null
@@ -1,64 +0,0 @@
-
-@import "DS-colors";
-
-
-/*
- * global
- */
-$headings: "Roboto", sans-serif;
-$headings-landing: "Roboto", sans-serif;
-$buttons: "Roboto", sans-serif;
-$font: "Roboto", sans-serif;
-$body-text-size: 14px;
-$white: #fff;
-$black: #000;
-$top-navigation-height: 92px; // top navigation height is: nav (55px) + breadcrumbs (37px)
-
-/*
- * standard mode
- */
-$body-text: $black;
-$primary-links: $light-blue-600;
-//
-$bg-body: $white;
-$bg-body-landing: $light-page-background;
-$bg-header: $light-blue-500;
-$bg-secondary: $light-blue-500;
-$bg-sidebar: $light-page-background;
-$bg-sidebar-active: $light-page-background;
-$bg-footer: $white;
-$bg-footer-landing: $light-grey-500;
-$bg-component: $light-page-background;
-$bg-card: $white;
-
-// notes, warnings//
-$note-color: $light-blue-500;
-$important-color: $light-amber-500;
-$warning-color: $light-red-700;
-
-$slider-bg: $light-blue-200;
-$slider-btn: $light-blue-500;
-$table-head: $light-grey-200;
-
-/*
- * night mode
- */
-$body-text-night: $white;
-$primary-links-night: $dark-grey-700;
-
-$bg-body-night: $dark-palette-background;
-$bg-body-landing-night: $dark-palette-background;
-$bg-header-night: $dark-blue-200;
-$bg-secondary-night: $dark-grey-100;
-$bg-sidebar-night: $dark-grey-100;
-$bg-sidebar-night-active: $dark-grey-100;
-$bg-footer-night: $dark-grey-100;
-$bg-footer-landing-night: $dark-grey-100;
-
-$bg-component-night: $dark-grey-200;
-$bg-card-night: $dark-grey-200;
-
-$active-sidebar-night: $dark-grey-800;
-
-$bg-search-results-night: $black;
-
diff --git a/_vendor/github.com/compose-spec/compose-spec/01-status.md b/_vendor/github.com/compose-spec/compose-spec/01-status.md
new file mode 100644
index 0000000000..58deb9213b
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/01-status.md
@@ -0,0 +1,24 @@
+## Status of this document
+
+This document specifies the Compose file format used to define multi-containers applications. Distribution of this document is unlimited.
+
+### Requirements and optional attributes
+
+The Compose specification includes properties designed to target a local [OCI](https://opencontainers.org/) container runtime,
+exposing Linux kernel specific configuration options, but also some Windows container specific properties. It is also designed for cloud platform features related to resource placement on a cluster, replicated application distribution, and scalability.
+
+We acknowledge that no Compose implementation is expected to support all attributes, and that support for some properties
+is platform dependent and can only be confirmed at runtime. The definition of a versioned schema to control the supported
+properties in a Compose file, established by the [docker-compose](https://github.com/docker/compose) tool where the Compose
+file format was designed, doesn't offer any guarantee to the end-user that attributes will be actually implemented.
+
+The specification defines the expected configuration syntax and behavior. Unless noted, supporting any of these is optional.
+
+A Compose implementation to parse a Compose file using unsupported attributes should warn users. We recommend the following implementors
+to support those running modes:
+
+* Default: warn the user about unsupported attributes, but ignore them
+* Strict: warn the user about unsupported attributes and reject the Compose file
+* Loose: ignore unsupported attributes AND unknown attributes (that were not defined by the spec by the time implementation was created)
+
+From this point onwards, references made to 'Compose' can be interpreted as 'a Compose implementation'.
diff --git a/_vendor/github.com/compose-spec/compose-spec/02-model.md b/_vendor/github.com/compose-spec/compose-spec/02-model.md
new file mode 100644
index 0000000000..c66cbf8a25
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/02-model.md
@@ -0,0 +1,127 @@
+## The Compose application model
+
+The Compose Specification lets you define a platform-agnostic container based application. Such an application is designed as a set of containers which have to both run together with adequate shared resources and communication channels.
+
+Computing components of an application are defined as [services](05-services.md). A service is an abstract concept implemented on platforms by running the same container image, and configuration, one or more times.
+
+Services communicate with each other through [networks](06-networks.md). In the Compose Specification, a network is a platform capability abstraction to establish an IP route between containers within services connected together. Low-level, platform-specific networking options are grouped into the Network definition and may be partially implemented on some platforms.
+
+Services store and share persistent data into [volumes](07-volumes.md). The Specification describes such a persistent data as a high-level filesystem mount with global options. Actual platform-specific implementation details are grouped into the volumes definition and may be partially implemented on some platforms.
+
+Some services require configuration data that is dependent on the runtime or platform. For this, the Specification defines a dedicated [configs](08-configs.md) concept. From a service container point of view, configs are comparable to volumes, in that they are files mounted into the container. But the actual definition involves distinct platform resources and services, which are abstracted by this type.
+
+A [secret](09-secrets.md) is a specific flavor of configuration data for sensitive data that should not be exposed without security considerations. Secrets are made available to services as files mounted into their containers, but the platform-specific resources to provide sensitive data are specific enough to deserve a distinct concept and definition within the Compose specification.
+
+>**Note**
+>
+> With volumes, configs and secrets you can have a simple declaration at the top-level and then add more platform-specific information at the service level.
+
+A project is an individual deployment of an application specification on a platform. A project's name, set with the the top-level [`name`](04-version-and-name.md) attribute, is used to group
+resources together and isolate them from other applications or other installation of the same Compose specified application with distinct parameters. If you are creating resources on a platform, you must prefix resource names by project and
+set the label `com.docker.compose.project`.
+
+Compose offers a way for users to set a custom project name and override this name, so that the same `compose.yaml` file can be deployed twice on the same infrastructure, without changes, by just passing a distinct name.
+
+Project names must contain only lowercase letters, decimal digits, dashes, and underscores, and must begin with a lowercase letter or decimal digit.
+
+### Illustrative example
+
+The following example illustrates the Compose Specification concepts outlined above. The example is non-normative.
+
+Consider an application split into a frontend web application and a backend service.
+
+The frontend is configured at runtime with an HTTP configuration file managed by infrastructure, providing an external domain name, and an HTTPS server certificate injected by the platform's secured secret store.
+
+The backend stores data in a persistent volume.
+
+Both services communicate with each other on an isolated back-tier network, while the frontend is also connected to a front-tier network and exposes port 443 for external usage.
+
+```mermaid
+ %%{ init: { 'flowchart': { 'curve': 'linear' } } }%%
+ flowchart LR
+ subgraph A[INFRASTRUCTURE]
+ direction TB
+ subgraph TOP[" "]
+ subgraph B1[Frontend Service]
+ fs["`**webapp**`"]
+ end
+ style B1 fill:#ccd6e8, stroke-width:0px
+ subgraph B2[Backend Service]
+ bs["`**database**`"]
+ end
+ style B2 fill:#ccd6e8, stroke-width:0px
+
+ end
+ style TOP fill:transparent, stroke-width:2px, stroke:#62affb, stroke-dasharray: 5 5
+ key[ro= read only\nr+w = read write]
+ style key fill:transparent, stroke-width:0px,text-align: left, size: 94px
+
+ direction TB
+ id2(Server\nCertificate)
+ id1(HTTP\nConfiguration)
+ id1 & id2 -.-|ro| B1
+ style id1 stroke:#000,stroke-width:1px,stroke-dasharray: 10
+ style id2 stroke:#000,stroke-width:1px,stroke-dasharray: 10
+ B2 ==r+w==> id3[(Persistent\nVolume)]
+ end
+ style A fill:#eeeeee, stroke-width:0px
+ direction LR
+ id4[External\nUser] ---id5(((443)))--->|Frontend\nNetwork| B1
+ style id4 stroke:#000,stroke-width:2px
+ B1 --Backend\nNetwork--> B2
+```
+
+The example application is composed of the following parts:
+
+- 2 services, backed by Docker images: `webapp` and `database`
+- 1 secret (HTTPS certificate), injected into the frontend
+- 1 configuration (HTTP), injected into the frontend
+- 1 persistent volume, attached to the backend
+- 2 networks
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ ports:
+ - "443:8043"
+ networks:
+ - front-tier
+ - back-tier
+ configs:
+ - httpd-config
+ secrets:
+ - server-certificate
+
+ backend:
+ image: awesome/database
+ volumes:
+ - db-data:/etc/data
+ networks:
+ - back-tier
+
+volumes:
+ db-data:
+ driver: flocker
+ driver_opts:
+ size: "10GiB"
+
+configs:
+ httpd-config:
+ external: true
+
+secrets:
+ server-certificate:
+ external: true
+
+networks:
+ # The presence of these objects is sufficient to define them
+ front-tier: {}
+ back-tier: {}
+```
+
+This example illustrates the distinction between volumes, configs and secrets. While all of them are all exposed
+to service containers as mounted files or directories, only a volume can be configured for read+write access.
+Secrets and configs are read-only. The volume configuration allows you to select a volume driver and pass driver options
+to tweak volume management according to the actual infrastructure. Configs and secrets rely on platform services,
+and are declared `external` as they are not managed as part of the application lifecycle. Compose uses a platform-specific lookup mechanism to retrieve runtime values.
diff --git a/_vendor/github.com/compose-spec/compose-spec/03-compose-file.md b/_vendor/github.com/compose-spec/compose-spec/03-compose-file.md
new file mode 100644
index 0000000000..85fc8cfc2e
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/03-compose-file.md
@@ -0,0 +1,23 @@
+## Compose file
+
+The Compose file is a [YAML](http://yaml.org/) file defining:
+- [Version](04-version-and-name.md) (Optional)
+- [Services](05-services.md) (Required)
+- [Networks](06-networks.md)
+- [Volumes](07-volumes.md)
+- [Configs](08-configs.md)
+- [Secrets](09-secrets.md)
+
+The default path for a Compose file is `compose.yaml` (preferred) or `compose.yml` that is placed in the working directory.
+Compose also supports `docker-compose.yaml` and `docker-compose.yml` for backwards compatibility of earlier versions.
+If both files exist, Compose prefers the canonical `compose.yaml`.
+
+You can use [fragments](10-fragments.md) and [extensions](11-extension.md) to keep your Compose file efficient and easy to maintain.
+
+Multiple Compose files can be [merged](13-merge.md) together to define the application model. The combination of YAML files are implemented by appending or overriding YAML elements based on the Compose file order you set.
+Simple attributes and maps get overridden by the highest order Compose file, lists get merged by appending. Relative
+paths are resolved based on the first Compose file's parent folder, whenever complimentary files being
+merged are hosted in other folders. As some Compose file elements can both be expressed as single strings or complex objects, merges apply to
+the expanded form.
+
+If you want to reuse other Compose files, or factor out parts of you application model into separate Compose files, you can also use [`include`](14-include.md). This is useful if your Compose application is dependent on another application which is managed by a different team, or needs to be shared with others.
diff --git a/_vendor/github.com/compose-spec/compose-spec/04-version-and-name.md b/_vendor/github.com/compose-spec/compose-spec/04-version-and-name.md
new file mode 100644
index 0000000000..89dc558b52
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/04-version-and-name.md
@@ -0,0 +1,27 @@
+## Version top-level element
+
+The top-level `version` property is defined by the Compose Specification for backward compatibility. It is only informative.
+
+Compose doesn't use `version` to select an exact schema to validate the Compose file, but
+prefers the most recent schema when it's implemented.
+
+Compose validates whether it can fully parse the Compose file. If some fields are unknown, typically
+because the Compose file was written with fields defined by a newer version of the Specification, you'll receive a warning message. Compose offers options to ignore unknown fields (as defined by ["loose"](01-status.md#requirements-and-optional-attributes) mode).
+
+## Name top-level element
+
+The top-level `name` property is defined by the Specification as the project name to be used if you don't set one explicitly.
+Compose offers a way for you to override this name, and sets a
+default project name to be used if the top-level `name` element is not set.
+
+Whenever a project name is defined by top-level `name` or by some custom mechanism, it is exposed for
+[interpolation](12-interpolation.md) and environment variable resolution as `COMPOSE_PROJECT_NAME`
+
+```yml
+services:
+ foo:
+ image: busybox
+ environment:
+ - COMPOSE_PROJECT_NAME
+ command: echo "I'm running ${COMPOSE_PROJECT_NAME}"
+```
diff --git a/_vendor/github.com/compose-spec/compose-spec/05-services.md b/_vendor/github.com/compose-spec/compose-spec/05-services.md
new file mode 100644
index 0000000000..e8ca68b239
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/05-services.md
@@ -0,0 +1,1730 @@
+## Services top-level element
+
+A service is an abstract definition of a computing resource within an application which can be scaled or replaced
+independently from other components. Services are backed by a set of containers, run by the platform
+according to replication requirements and placement constraints. As services are backed by containers, they are defined
+by a Docker image and set of runtime arguments. All containers within a service are identically created with these
+arguments.
+
+A Compose file must declare a `services` top-level element as a map whose keys are string representations of service names,
+and whose values are service definitions. A service definition contains the configuration that is applied to each
+service container.
+
+Each service may also include a `build` section, which defines how to create the Docker image for the service.
+Compose supports building docker images using this service definition. If not used, the `build` section is ignored and the Compose file is still considered valid. Build support is an optional aspect of the Compose Specification, and is
+described in detail in the [Compose Build Specification](build.md) documentation.
+
+Each service defines runtime constraints and requirements to run its containers. The `deploy` section groups
+these constraints and allows the platform to adjust the deployment strategy to best match containers' needs with
+available resources. Deploy support is an optional aspect of the Compose Specification, and is
+described in detail in the [Compose Deploy Specification](deploy.md) documentation.
+If not implemented the `deploy` section is ignored and the Compose file is still considered valid.
+
+### attach
+
+When `attach` is defined and set to `false` Compose does not collect service logs,
+until you explicitly request it to.
+
+The default service configuration is `attach: true`.
+
+### build
+
+`build` specifies the build configuration for creating a container image from source, as defined in the [Compsoe Build Specification](build.md).
+
+### blkio_config
+
+`blkio_config` defines a set of configuration options to set block IO limits for a service.
+
+```yml
+services:
+ foo:
+ image: busybox
+ blkio_config:
+ weight: 300
+ weight_device:
+ - path: /dev/sda
+ weight: 400
+ device_read_bps:
+ - path: /dev/sdb
+ rate: '12mb'
+ device_read_iops:
+ - path: /dev/sdb
+ rate: 120
+ device_write_bps:
+ - path: /dev/sdb
+ rate: '1024k'
+ device_write_iops:
+ - path: /dev/sdb
+ rate: 30
+```
+
+#### device_read_bps, device_write_bps
+
+Set a limit in bytes per second for read / write operations on a given device.
+Each item in the list must have two keys:
+
+- `path`: Defines the symbolic path to the affected device.
+- `rate`: Either as an integer value representing the number of bytes or as a string expressing a byte value.
+
+#### device_read_iops, device_write_iops
+
+Set a limit in operations per second for read / write operations on a given device.
+Each item in the list must have two keys:
+
+- `path`: Defines the symbolic path to the affected device.
+- `rate`: As an integer value representing the permitted number of operations per second.
+
+#### weight
+
+Modify the proportion of bandwidth allocated to a service relative to other services.
+Takes an integer value between 10 and 1000, with 500 being the default.
+
+#### weight_device
+
+Fine-tune bandwidth allocation by device. Each item in the list must have two keys:
+
+- `path`: Defines the symbolic path to the affected device.
+- `weight`: An integer value between 10 and 1000.
+
+### cpu_count
+
+`cpu_count` defines the number of usable CPUs for service container.
+
+### cpu_percent
+
+`cpu_percent` defines the usable percentage of the available CPUs.
+
+### cpu_shares
+
+`cpu_shares` defines, as integer value, a service container's relative CPU weight versus other containers.
+
+### cpu_period
+
+`cpu_period` configures CPU CFS (Completely Fair Scheduler) period when a platform is based
+on Linux kernel.
+
+### cpu_quota
+
+`cpu_quota` configures CPU CFS (Completely Fair Scheduler) quota when a platform is based
+on Linux kernel.
+
+### cpu_rt_runtime
+
+`cpu_rt_runtime` configures CPU allocation parameters for platforms with support for realtime scheduler. It can be either
+an integer value using microseconds as unit or a [duration](11-extension.md#specifying-durations).
+
+```yml
+ cpu_rt_runtime: '400ms'
+ cpu_rt_runtime: 95000`
+```
+
+### cpu_rt_period
+
+`cpu_rt_period` configures CPU allocation parameters for platforms with support for realtime scheduler. It can be either
+an integer value using microseconds as unit or a [duration](11-extension.md#specifying-durations).
+
+```yml
+ cpu_rt_period: '1400us'
+ cpu_rt_period: 11000`
+```
+
+### cpus
+
+_DEPRECATED: use [deploy.limits.cpus](deploy.md#cpus)_
+
+`cpus` define the number of (potentially virtual) CPUs to allocate to service containers. This is a fractional number.
+`0.000` means no limit.
+
+### cpuset
+
+`cpuset` defines the explicit CPUs in which to allow execution. Can be a range `0-3` or a list `0,1`
+
+### cap_add
+
+`cap_add` specifies additional container [capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)
+as strings.
+
+```yaml
+cap_add:
+ - ALL
+```
+
+### cap_drop
+
+`cap_drop` specifies container [capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html) to drop
+as strings.
+
+```yaml
+cap_drop:
+ - NET_ADMIN
+ - SYS_ADMIN
+```
+
+### cgroup
+
+`cgroup` specifies the cgroup namespace to join. When unset, it is the container runtime's decision to
+select which cgroup namespace to use, if supported.
+
+- `host`: Runs the container in the Container runtime cgroup namespace.
+- `private`: Runs the container in its own private cgroup namespace.
+
+### cgroup_parent
+
+`cgroup_parent` specifies an optional parent [cgroup](https://man7.org/linux/man-pages/man7/cgroups.7.html) for the container.
+
+```yaml
+cgroup_parent: m-executor-abcd
+```
+
+### command
+
+`command` overrides the default command declared by the container image, for example by Dockerfile's `CMD`.
+
+```yaml
+command: bundle exec thin -p 3000
+```
+
+The value can also be a list, in a manner similar to [Dockerfile](https://docs.docker.com/engine/reference/builder/#cmd):
+
+```yaml
+command: [ "bundle", "exec", "thin", "-p", "3000" ]
+```
+
+If the value is `null`, the default command from the image is used.
+
+If the value is `[]` (empty list) or `''` (empty string), the default command declared by the image is ignored,
+i.e. overridden to be empty.
+
+### configs
+
+Configs allow services to adapt their behaviour without the need to rebuild a Docker image.
+Services can only access configs when explicitly granted by the `configs` attribute. Two different syntax variants are supported.
+
+Compose reports an error if `config` doesn't exist on the platform or isn't defined in the
+[`configs` top-level element](08-configs.md) in the Compose file.
+
+There are two syntaxes defined for configs. To remain compliant to this specification, an implementation
+must support both syntaxes. Implementations must allow use of both short and long syntaxes within the same document.
+
+You can grant a service access to multiple configs, and you can mix long and short syntax.
+
+#### Short syntax
+
+The short syntax variant only specifies the config name. This grants the
+container access to the config and mounts it as files into a service’s container’s filesystem. The location of the mount point within the container defaults to `/` in Linux containers, and `C:\` in Windows containers.
+
+The following example uses the short syntax to grant the `redis` service
+access to the `my_config` and `my_other_config` configs. The value of
+`my_config` is set to the contents of the file `./my_config.txt`, and
+`my_other_config` is defined as an external resource, which means that it has
+already been defined in the platform. If the external config does not exist,
+the deployment fails.
+
+```yml
+services:
+ redis:
+ image: redis:latest
+ configs:
+ - my_config
+ - my_other_config
+configs:
+ my_config:
+ file: ./my_config.txt
+ my_other_config:
+ external: true
+```
+
+#### Long syntax
+
+The long syntax provides more granularity in how the config is created within the service's task containers.
+
+- `source`: The name of the config as it exists in the platform.
+- `target`: The path and name of the file to be mounted in the service's
+ task containers. Defaults to `/` if not specified.
+- `uid` and `gid`: The numeric UID or GID that owns the mounted config file
+ within the service's task containers. Default value when not specified is USER running container.
+- `mode`: The [permissions](https://wintelguy.com/permissions-calc.pl) for the file that is mounted within the service's
+ task containers, in octal notation. Default value is world-readable (`0444`).
+ Writable bit must be ignored. The executable bit can be set.
+
+The following example sets the name of `my_config` to `redis_config` within the
+container, sets the mode to `0440` (group-readable) and sets the user and group
+to `103`. The `redis` service does not have access to the `my_other_config`
+config.
+
+```yml
+services:
+ redis:
+ image: redis:latest
+ configs:
+ - source: my_config
+ target: /redis_config
+ uid: "103"
+ gid: "103"
+ mode: 0440
+configs:
+ my_config:
+ external: true
+ my_other_config:
+ external: true
+```
+
+### container_name
+
+`container_name` is a string that specifies a custom container name, rather than a name generated by default.
+
+```yml
+container_name: my-web-container
+```
+
+Compose does not scale a service beyond one container if the Compose file specifies a
+`container_name`. Attempting to do so results in an error.
+
+`container_name` follows the regex format of `[a-zA-Z0-9][a-zA-Z0-9_.-]+`
+
+### credential_spec
+
+`credential_spec` configures the credential spec for a managed service account.
+
+If you have services that use Windows containers, you can use `file:` and
+`registry:` protocols for `credential_spec`. Compose also supports additional
+protocols for custom use-cases.
+
+The `credential_spec` must be in the format `file://` or `registry://`.
+
+```yml
+credential_spec:
+ file: my-credential-spec.json
+```
+
+When using `registry:`, the credential spec is read from the Windows registry on
+the daemon's host. A registry value with the given name must be located in:
+
+ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs
+
+The following example loads the credential spec from a value named `my-credential-spec`
+in the registry:
+
+```yml
+credential_spec:
+ registry: my-credential-spec
+```
+
+#### Example gMSA configuration
+
+When configuring a gMSA credential spec for a service, you only need
+to specify a credential spec with `config`, as shown in the following example:
+
+```yml
+services:
+ myservice:
+ image: myimage:latest
+ credential_spec:
+ config: my_credential_spec
+
+configs:
+ my_credentials_spec:
+ file: ./my-credential-spec.json|
+```
+
+### depends_on
+
+`depends_on` expresses startup and shutdown dependencies between services.
+
+#### Short syntax
+
+The short syntax variant only specifies service names of the dependencies.
+Service dependencies cause the following behaviors:
+
+- Compose creates services in dependency order. In the following
+ example, `db` and `redis` are created before `web`.
+
+- Compose removes services in dependency order. In the following
+ example, `web` is removed before `db` and `redis`.
+
+Simple example:
+
+```yml
+services:
+ web:
+ build: .
+ depends_on:
+ - db
+ - redis
+ redis:
+ image: redis
+ db:
+ image: postgres
+```
+
+Compose guarantees dependency services have been started before
+starting a dependent service.
+Compose waits for dependency services to be "ready" before
+starting a dependent service.
+
+#### Long syntax
+
+The long form syntax enables the configuration of additional fields that can't be
+expressed in the short form.
+
+- `restart`: When set to `true` Compose restarts this service after it updates the dependency service.
+ This applies to an explicit restart controlled by a Compose operation, and excludes automated restart by the container runtime
+ after the container dies.
+
+- `condition`: Sets the condition under which dependency is considered satisfied
+ - `service_started`: An equivalent of the short syntax described above
+ - `service_healthy`: Specifies that a dependency is expected to be "healthy"
+ (as indicated by [healthcheck](#healthcheck)) before starting a dependent
+ service.
+ - `service_completed_successfully`: Specifies that a dependency is expected to run
+ to successful completion before starting a dependent service.
+- `required`: When set to `false` Compose only warns you when the dependency service isn't started or available. If it's not defined
+ the default value of `required` is `true`.
+
+Service dependencies cause the following behaviors:
+
+- Compose creates services in dependency order. In the following
+ example, `db` and `redis` are created before `web`.
+
+- Compose waits for healthchecks to pass on dependencies
+ marked with `service_healthy`. In the following example, `db` is expected to
+ be "healthy" before `web` is created.
+
+- Compose removes services in dependency order. In the following
+ example, `web` is removed before `db` and `redis`.
+
+```yml
+services:
+ web:
+ build: .
+ depends_on:
+ db:
+ condition: service_healthy
+ restart: true
+ redis:
+ condition: service_started
+ redis:
+ image: redis
+ db:
+ image: postgres
+```
+
+Compose guarantees dependency services are started before
+starting a dependent service.
+Compose guarantees dependency services marked with
+`service_healthy` are "healthy" before starting a dependent service.
+
+### deploy
+
+`deploy` specifies the configuration for the deployment and lifecycle of services, as defined [in the Compose Deploy Specification](deploy.md).
+
+### device_cgroup_rules
+
+`device_cgroup_rules` defines a list of device cgroup rules for this container.
+The format is the same format the Linux kernel specifies in the [Control Groups
+Device Whitelist Controller](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/devices.html).
+
+```yml
+device_cgroup_rules:
+ - 'c 1:3 mr'
+ - 'a 7:* rmw'
+```
+
+### devices
+
+`devices` defines a list of device mappings for created containers in the form of
+`HOST_PATH:CONTAINER_PATH[:CGROUP_PERMISSIONS]`.
+
+```yml
+devices:
+ - "/dev/ttyUSB0:/dev/ttyUSB0"
+ - "/dev/sda:/dev/xvda:rwm"
+```
+
+### dns
+
+`dns` defines custom DNS servers to set on the container network interface configuration. It can be a single value or a list.
+
+```yml
+dns: 8.8.8.8
+```
+
+```yml
+dns:
+ - 8.8.8.8
+ - 9.9.9.9
+```
+
+### dns_opt
+
+`dns_opt` list custom DNS options to be passed to the container’s DNS resolver (`/etc/resolv.conf` file on Linux).
+
+```yml
+dns_opt:
+ - use-vc
+ - no-tld-query
+```
+
+### dns_search
+
+`dns` defines custom DNS search domains to set on container network interface configuration. It can be a single value or a list.
+
+```yml
+dns_search: example.com
+```
+
+```yml
+dns_search:
+ - dc1.example.com
+ - dc2.example.com
+```
+
+### domainname
+
+`domainname` declares a custom domain name to use for the service container. It must be a valid RFC 1123 hostname.
+
+### entrypoint
+
+`entrypoint` declares the default entrypoint for the service container.
+This overrides the `ENTRYPOINT` instruction from the service's Dockerfile.
+
+If `entrypoint` is non-null, Compose ignores any default command from the image, for example the `CMD`
+instruction in the Dockerfile.
+
+See also [`command`](#command) to set or override the default command to be executed by the entrypoint process.
+
+In its short form, the value can be defined as a string:
+```yml
+entrypoint: /code/entrypoint.sh
+```
+
+Alternatively, the value can also be a list, in a manner similar to the
+[Dockerfile](https://docs.docker.com/engine/reference/builder/#cmd):
+
+```yml
+entrypoint:
+ - php
+ - -d
+ - zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
+ - -d
+ - memory_limit=-1
+ - vendor/bin/phpunit
+```
+
+If the value is `null`, the default entrypoint from the image is used.
+
+If the value is `[]` (empty list) or `''` (empty string), the default entrypoint declared by the image is ignored,
+i.e. overridden to be empty.
+
+### env_file
+
+`env_file` adds environment variables to the container based on the file content.
+
+```yml
+env_file: .env
+```
+
+`env_file` can also be a list. The files in the list are processed from the top down. For the same variable
+specified in two env files, the value from the last file in the list stands.
+
+```yml
+env_file:
+ - ./a.env
+ - ./b.env
+```
+
+Relative path are resolved from the Compose file's parent folder. As absolute paths prevent the Compose
+file from being portable, Compose warns you when such a path is used to set `env_file`.
+
+Environment variables declared in the [environment](#environment) section override these values. This holds true even if those values are
+empty or undefined.
+
+#### Env_file format
+
+Each line in an `.env` file must be in `VAR[=[VAL]]` format. Lines beginning with `#` are ignored.
+Blank lines are also ignored.
+
+The value of `VAL` is used as a raw string and not modified at all. If the value is surrounded by quotes, as is often the case for shell variables, the quotes are included in the value passed to containers
+created by Compose.
+
+`VAL` may be omitted, in such cases the variable value is an empty string.
+`=VAL` may be omitted, in such cases the variable is unset.
+
+```bash
+# Set Rails/Rack environment
+RACK_ENV=development
+VAR="quoted"
+```
+
+### environment
+
+`environment` defines environment variables set in the container. `environment` can use either an array or a
+map. Any boolean values; true, false, yes, no, should be enclosed in quotes to ensure
+they are not converted to True or False by the YAML parser.
+
+Environment variables can be declared by a single key (no value to equals sign). In this case Compose
+relies on you to resolve the value. If the value is not resolved, the variable
+is unset and is removed from the service container environment.
+
+Map syntax:
+
+```yml
+environment:
+ RACK_ENV: development
+ SHOW: "true"
+ USER_INPUT:
+```
+
+Array syntax:
+
+```yml
+environment:
+ - RACK_ENV=development
+ - SHOW=true
+ - USER_INPUT
+```
+
+When both `env_file` and `environment` are set for a service, values set by `environment` have precedence.
+
+### expose
+
+`expose` defines the ports that Compose exposes from the container. These ports must be
+accessible to linked services and should not be published to the host machine. Only the internal container
+ports can be specified.
+
+```yml
+expose:
+ - "3000"
+ - "8000"
+```
+
+> **Note**
+>
+> If the Dockerfile for the image already exposes ports, it is visible to other containers on the network even is `expose` is not set in your Compose file.
+
+### extends
+
+`extends` lets you share common configurations among different files, or even different projects entirely. With `extends` you can define a common set of service options in one place and refer to it from anywhere. You can refer to another Compose file and select a service you want to also use in your own application, with the ability to override some attributes for your own needs.
+
+You can use `extends` on any service together with other configuration keys. The `extends` value must be a mapping
+defined with a required `service` and an optional `file` key.
+
+```yaml
+extends:
+ file: common.yml
+ service: webapp
+```
+
+- `service`: Defines the name of the service being referenced as a base, for example `web` or `database`.
+- `file`: The location of a Compose configuration file defining that service.
+
+#### Restrictions
+
+The following restrictions apply to the service being referenced:
+
+- Services that have dependencies on other services cannot be used as a base. Therefore, any key
+ that introduces a dependency on another service is incompatible with `extends`. The
+ non-exhaustive list of such keys is: `links`, `volumes_from`, `container` mode (in `ipc`, `pid`,
+ `network_mode` and `net`), `service` mode (in `ipc`, `pid` and `network_mode`), `depends_on`.
+- Services cannot have circular references with `extends`.
+
+Compose returns an error in all of these cases.
+
+#### Finding referenced service
+
+`file` value can be:
+
+- Not present.
+ This indicates that another service within the same Compose file is being referenced.
+- File path, which can be either:
+ - Relative path. This path is considered as relative to the location of the main Compose
+ file.
+ - Absolute path.
+
+A service denoted by `service` must be present in the identified referenced Compose file.
+Compose returns an error if:
+
+- The service denoted by `service` is not found.
+- The Compose file denoted by `file` is not found.
+
+#### Merging service definitions
+
+Two service definitions, the main one in the current Compose file and the referenced one
+specified by `extends`, are merged in the following way:
+
+- Mappings: Keys in mappings of the main service definition override keys in mappings
+ of the referenced service definition. Keys that aren't overridden are included as is.
+- Sequences: Items are combined together into a new sequence. The order of elements is
+ preserved with the referenced items coming first and main items after.
+- Scalars: Keys in the main service definition take precedence over keys in the
+ referenced one.
+
+##### Mappings
+
+The following keys should be treated as mappings: `annotations`, `build.args`, `build.labels`,
+`build.extra_hosts`, `deploy.labels`, `deploy.update_config`, `deploy.rollback_config`,
+`deploy.restart_policy`, `deploy.resources.limits`, `environment`, `healthcheck`,
+`labels`, `logging.options`, `sysctls`, `storage_opt`, `extra_hosts`, `ulimits`.
+
+One exception that applies to `healthcheck` is that the main mapping cannot specify
+`disable: true` unless the referenced mapping also specifies `disable: true`. Compose returns an error in this case.
+
+For example, the input below:
+
+```yaml
+services:
+ common:
+ image: busybox
+ environment:
+ TZ: utc
+ PORT: 80
+ cli:
+ extends:
+ service: common
+ environment:
+ PORT: 8080
+```
+
+Produces the following configuration for the `cli` service. The same output is
+produced if array syntax is used.
+
+```yaml
+environment:
+ PORT: 8080
+ TZ: utc
+image: busybox
+```
+
+Items under `blkio_config.device_read_bps`, `blkio_config.device_read_iops`,
+`blkio_config.device_write_bps`, `blkio_config.device_write_iops`, `devices` and
+`volumes` are also treated as mappings where key is the target path inside the
+container.
+
+For example, the input below:
+
+```yaml
+services:
+ common:
+ image: busybox
+ volumes:
+ - common-volume:/var/lib/backup/data:rw
+ cli:
+ extends:
+ service: common
+ volumes:
+ - cli-volume:/var/lib/backup/data:ro
+```
+
+Produces the following configuration for the `cli` service. Note that the mounted path
+now points to the new volume name and `ro` flag was applied.
+
+```yaml
+image: busybox
+volumes:
+- cli-volume:/var/lib/backup/data:ro
+```
+
+If the referenced service definition contains `extends` mapping, the items under it
+are simply copied into the new merged definition. The merging process is then kicked
+off again until no `extends` keys are remaining.
+
+For example, the input below:
+
+```yaml
+services:
+ base:
+ image: busybox
+ user: root
+ common:
+ image: busybox
+ extends:
+ service: base
+ cli:
+ extends:
+ service: common
+```
+
+Produces the following configuration for the `cli` service. Here, `cli` services
+gets `user` key from `common` service, which in turn gets this key from `base`
+service.
+
+```yaml
+image: busybox
+user: root
+```
+
+##### Sequences
+
+The following keys should be treated as sequences: `cap_add`, `cap_drop`, `configs`,
+`deploy.placement.constraints`, `deploy.placement.preferences`,
+`deploy.reservations.generic_resources`, `device_cgroup_rules`, `expose`,
+`external_links`, `ports`, `secrets`, `security_opt`.
+Any duplicates resulting from the merge are removed so that the sequence only
+contains unique elements.
+
+For example, the input below:
+
+```yaml
+services:
+ common:
+ image: busybox
+ security_opt:
+ - label:role:ROLE
+ cli:
+ extends:
+ service: common
+ security_opt:
+ - label:user:USER
+```
+
+Produces the following configuration for the `cli` service.
+
+```yaml
+image: busybox
+security_opt:
+- label:role:ROLE
+- label:user:USER
+```
+
+In case list syntax is used, the following keys should also be treated as sequences:
+`dns`, `dns_search`, `env_file`, `tmpfs`. Unlike sequence fields mentioned above,
+duplicates resulting from the merge are not removed.
+
+##### Scalars
+
+Any other allowed keys in the service definition should be treated as scalars.
+
+### annotations
+
+`annotations` defines annotations for the container. `annotations` can use either an array or a map.
+
+```yml
+annotations:
+ com.example.foo: bar
+```
+
+```yml
+annotations:
+ - com.example.foo=bar
+```
+
+### external_links
+
+`external_links` link service containers to services managed outside of your Compose application.
+`external_links` define the name of an existing service to retrieve using the platform lookup mechanism.
+An alias of the form `SERVICE:ALIAS` can be specified.
+
+```yml
+external_links:
+ - redis
+ - database:mysql
+ - database:postgresql
+```
+
+### extra_hosts
+
+`extra_hosts` adds hostname mappings to the container network interface configuration (`/etc/hosts` for Linux).
+
+#### Short syntax
+Short syntax uses plain strings in a list. Values must set hostname and IP address for additional hosts in the form of `HOSTNAME:IP`.
+
+```yml
+extra_hosts:
+ - "somehost:162.242.195.82"
+ - "otherhost:50.31.209.229"
+```
+
+#### Long syntax
+Alternatively, `extra_hosts` can be set as a mapping between hostname(s) and IP(s)
+
+```yml
+extra_hosts:
+ somehost: "162.242.195.82"
+ otherhost: "50.31.209.229"
+```
+
+Compose creates a matching entry with the IP address and hostname in the container's network
+configuration, which means for Linux `/etc/hosts` get extra lines:
+
+```
+162.242.195.82 somehost
+50.31.209.229 otherhost
+```
+
+### group_add
+
+`group_add` specifies additional groups, by name or number, which the user inside the container must be a member of.
+
+An example of where this is useful is when multiple containers (running as different users) need to all read or write
+the same file on a shared volume. That file can be owned by a group shared by all the containers, and specified in
+`group_add`.
+
+```yml
+services:
+ myservice:
+ image: alpine
+ group_add:
+ - mail
+```
+
+Running `id` inside the created container must show that the user belongs to the `mail` group, which would not have
+been the case if `group_add` were not declared.
+
+### healthcheck
+
+`healthcheck` declares a check that's run to determine whether or not the service containers are "healthy". It works in the same way, and has the same default values, as the
+[HEALTHCHECK Dockerfile instruction](https://docs.docker.com/engine/reference/builder/#healthcheck)
+set by the service's Docker image. Your Compose file can override the values set in the Dockerfile.
+
+```yml
+healthcheck:
+ test: ["CMD", "curl", "-f", "http://localhost"]
+ interval: 1m30s
+ timeout: 10s
+ retries: 3
+ start_period: 40s
+ start_interval: 5s
+```
+
+`interval`, `timeout`, `start_period`, and `start_interval` are [specified as durations](11-extension.md#specifying-durations).
+
+`test` defines the command Compose runs to check container health. It can be
+either a string or a list. If it's a list, the first item must be either `NONE`, `CMD` or `CMD-SHELL`.
+If it's a string, it's equivalent to specifying `CMD-SHELL` followed by that string.
+
+```yml
+# Hit the local web app
+test: ["CMD", "curl", "-f", "http://localhost"]
+```
+
+Using `CMD-SHELL` runs the command configured as a string using the container's default shell
+(`/bin/sh` for Linux). Both forms below are equivalent:
+
+```yml
+test: ["CMD-SHELL", "curl -f http://localhost || exit 1"]
+```
+
+```yml
+test: curl -f https://localhost || exit 1
+```
+
+`NONE` disables the healthcheck, and is mostly useful to disable the Healthcheck Dockerfile instruction set by the service's Docker image. Alternatively,
+the healthcheck set by the image can be disabled by setting `disable: true`:
+
+```yml
+healthcheck:
+ disable: true
+```
+
+### hostname
+
+`hostname` declares a custom host name to use for the service container. It must be a valid RFC 1123 hostname.
+
+### image
+
+`image` specifies the image to start the container from. `image` must follow the Open Container Specification
+[addressable image format](https://github.com/opencontainers/org/blob/master/docs/docs/introduction/digests.md),
+as `[/][/][:|@]`.
+
+```yml
+ image: redis
+ image: redis:5
+ image: redis@sha256:0ed5d5928d4737458944eb604cc8509e245c3e19d02ad83935398bc4b991aac7
+ image: library/redis
+ image: docker.io/library/redis
+ image: my_private.registry:5000/redis
+```
+
+If the image does not exist on the platform, Compose attempts to pull it based on the `pull_policy`.
+If you are also using the [Compose Build Specification](build.md), there are alternative options for controlling the precedence of
+pull over building the image from source, however pulling the image is the default behavior.
+
+`image` may be omitted from a Compose file as long as a `build` section is declared. If you are not using the Compose Build Specification, Compose won't work if `image` is missing from the Compose file.
+
+### init
+
+`init` runs an init process (PID 1) inside the container that forwards signals and reaps processes.
+Set this option to `true` to enable this feature for the service.
+
+```yml
+services:
+ web:
+ image: alpine:latest
+ init: true
+```
+
+The init binary that is used is platform specific.
+
+### ipc
+
+`ipc` configures the IPC isolation mode set by the service container. Available
+values are platform specific, but Compose defines specific values
+which must be implemented as described if supported:
+
+- `shareable`: Gives the container its own private IPC namespace, with a
+ possibility to share it with other containers.
+- `service:{name}`: Makes the container join another container's
+ (`shareable`) IPC namespace.
+
+```yml
+ ipc: "shareable"
+ ipc: "service:[service name]"
+```
+
+### uts
+
+`uts` configures the UTS namespace mode set for the service container. When unspecified
+it is the runtime's decision to assign a UTS namespace, if supported. Available values are:
+
+- `'host'`: Results in the container using the same UTS namespace as the host.
+
+```yml
+ uts: "host"
+```
+
+### isolation
+
+`isolation` specifies a container’s isolation technology. Supported values are platform specific.
+
+### labels
+
+`labels` add metadata to containers. You can use either an array or a map.
+
+It's recommended that you use reverse-DNS notation to prevent your labels from conflicting with
+those used by other software.
+
+```yml
+labels:
+ com.example.description: "Accounting webapp"
+ com.example.department: "Finance"
+ com.example.label-with-empty-value: ""
+```
+
+```yml
+labels:
+ - "com.example.description=Accounting webapp"
+ - "com.example.department=Finance"
+ - "com.example.label-with-empty-value"
+```
+
+Compose creates containers with canonical labels:
+
+- `com.docker.compose.project` set on all resources created by Compose to the user project name
+- `com.docker.compose.service` set on service containers with service name as defined in the Compose file
+
+The `com.docker.compose` label prefix is reserved. Specifying labels with this prefix in the Compose file
+results in a runtime error.
+
+### links
+
+> **Note**
+>
+> Availability of the `links` attribute is implementation specific.
+
+`links` defines a network link to containers in another service. Either specify both the service name and
+a link alias (`SERVICE:ALIAS`), or just the service name.
+
+```yml
+web:
+ links:
+ - db
+ - db:database
+ - redis
+```
+
+Containers for the linked service are reachable at a hostname identical to the alias, or the service name
+if no alias is specified.
+
+Links are not required to enable services to communicate. When no specific network configuration is set,
+any service is able to reach any other service at that service’s name on the `default` network. If services
+do declare networks they are attached to, `links` does not override the network configuration and services not
+attached to a shared network are not be able to communicate. Compose doesn't warn you about a configuration mismatch.
+
+Links also express implicit dependency between services in the same way as
+[depends_on](#depends_on), so they determine the order of service startup.
+
+### logging
+
+`logging` defines the logging configuration for the service.
+
+```yml
+logging:
+ driver: syslog
+ options:
+ syslog-address: "tcp://192.168.0.42:123"
+```
+
+The `driver` name specifies a logging driver for the service's containers. The default and available values
+are platform specific. Driver specific options can be set with `options` as key-value pairs.
+
+### network_mode
+
+`network_mode` sets a service container's network mode. Available values are platform specific, but Compose defines specific values which must be implemented as described if supported:
+
+- `none`: Turns off all container networking.
+- `host`: Gives the container raw access to the host's network interface.
+- `service:{name}`: Gives the containers access to the specified service only.
+
+```yml
+ network_mode: "host"
+ network_mode: "none"
+ network_mode: "service:[service name]"
+```
+
+When set, the [`networks`](#networks) attribute is not allowed and Compose rejects any
+Compose file containing both attributes.
+
+### networks
+
+`networks` defines the networks that service containers are attached to, referencing entries under the
+[top-level `networks` key](06-networks.md).
+
+```yml
+services:
+ some-service:
+ networks:
+ - some-network
+ - other-network
+```
+
+#### aliases
+
+`aliases` declares alternative hostnames for the service on the network. Other containers on the same
+network can use either the service name or an alias to connect to one of the service's containers.
+
+Since `aliases` are network-scoped, the same service can have different aliases on different networks.
+
+> **Note**
+> A network-wide alias can be shared by multiple containers, and even by multiple services.
+> If it is, then exactly which container the name resolves to is not guaranteed.
+
+```yml
+services:
+ some-service:
+ networks:
+ some-network:
+ aliases:
+ - alias1
+ - alias3
+ other-network:
+ aliases:
+ - alias2
+```
+
+In the following example, service `frontend` is able to reach the `backend` service at
+the hostname `backend` or `database` on the `back-tier` network. The service `monitoring`
+is able to reach same `backend` service at `backend` or `mysql` on the `admin` network.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ networks:
+ - front-tier
+ - back-tier
+
+ monitoring:
+ image: awesome/monitoring
+ networks:
+ - admin
+
+ backend:
+ image: awesome/backend
+ networks:
+ back-tier:
+ aliases:
+ - database
+ admin:
+ aliases:
+ - mysql
+
+networks:
+ front-tier:
+ back-tier:
+ admin:
+```
+
+#### ipv4_address, ipv6_address
+
+Specify a static IP address for a service container when joining the network.
+
+The corresponding network configuration in the [top-level networks section](06-networks.md) must have an
+`ipam` attribute with subnet configurations covering each static address.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ networks:
+ front-tier:
+ ipv4_address: 172.16.238.10
+ ipv6_address: 2001:3984:3989::10
+
+networks:
+ front-tier:
+ ipam:
+ driver: default
+ config:
+ - subnet: "172.16.238.0/24"
+ - subnet: "2001:3984:3989::/64"
+```
+
+#### link_local_ips
+
+`link_local_ips` specifies a list of link-local IPs. Link-local IPs are special IPs which belong to a well
+known subnet and are purely managed by the operator, usually dependent on the architecture where they are
+deployed. Implementation is platform specific.
+
+Example:
+
+```yaml
+services:
+ app:
+ image: busybox
+ command: top
+ networks:
+ app_net:
+ link_local_ips:
+ - 57.123.22.11
+ - 57.123.22.13
+networks:
+ app_net:
+ driver: bridge
+```
+
+#### priority
+
+`priority` indicates in which order Compose connects the service’s containers to its
+networks. If unspecified, the default value is 0.
+
+In the following example, the app service connects to `app_net_1` first as it has the highest priority. It then connects to `app_net_3`, then `app_net_2`, which uses the default priority value of 0.
+
+```yaml
+services:
+ app:
+ image: busybox
+ command: top
+ networks:
+ app_net_1:
+ priority: 1000
+ app_net_2:
+
+ app_net_3:
+ priority: 100
+networks:
+ app_net_1:
+ app_net_2:
+ app_net_3:
+```
+
+### mac_address
+
+`mac_address` sets a MAC address for the service container.
+
+### mem_limit
+
+_DEPRECATED: use [deploy.limits.memory](deploy.md#memory)_
+
+### mem_reservation
+
+_DEPRECATED: use [deploy.reservations.memory](deploy.md#memory)_
+
+### mem_swappiness
+
+`mem_swappiness` defines as a percentage, a value between 0 and 100, for the host kernel to swap out
+anonymous memory pages used by a container.
+
+- `0`: Turns off anonymous page swapping.
+- `100`: Sets all anonymous pages as swappable.
+
+The default value is platform specific.
+
+### memswap_limit
+
+`memswap_limit` defines the amount of memory the container is allowed to swap to disk. This is a modifier
+attribute that only has meaning if [`memory`](deploy.md#memory) is also set. Using swap lets the container write excess
+memory requirements to disk when the container has exhausted all the memory that is available to it.
+There is a performance penalty for applications that swap memory to disk often.
+
+- If `memswap_limit` is set to a positive integer, then both `memory` and `memswap_limit` must be set. `memswap_limit` represents the total amount of memory and swap that can be used, and `memory` controls the amount used by non-swap memory. So if `memory`="300m" and `memswap_limit`="1g", the container can use 300m of memory and 700m (1g - 300m) swap.
+- If `memswap_limit` is set to 0, the setting is ignored, and the value is treated as unset.
+- If `memswap_limit` is set to the same value as `memory`, and `memory` is set to a positive integer, the container does not have access to swap.
+- If `memswap_limit` is unset, and `memory` is set, the container can use as much swap as the `memory` setting, if the host container has swap memory configured. For instance, if `memory`="300m" and `memswap_limit` is not set, the container can use 600m in total of memory and swap.
+- If `memswap_limit` is explicitly set to -1, the container is allowed to use unlimited swap, up to the amount available on the host system.
+
+### oom_kill_disable
+
+If `oom_kill_disable` is set, Compose configures the platform so it won't kill the container in case
+of memory starvation.
+
+### oom_score_adj
+
+`oom_score_adj` tunes the preference for containers to be killed by platform in case of memory starvation. Value must
+be within [-1000,1000] range.
+
+### pid
+
+`pid` sets the PID mode for container created by Compose.
+Supported values are platform specific.
+
+### pids_limit
+
+_DEPRECATED: use [deploy.reservations.pids](deploy.md#pids)_
+
+`pids_limit` tunes a container’s PIDs limit. Set to -1 for unlimited PIDs.
+
+```yml
+pids_limit: 10
+```
+
+### platform
+
+`platform` defines the target platform the containers for the service run on. It uses the `os[/arch[/variant]]` syntax.
+
+The values of `os`, `arch`, and `variant` must conform to the convention used by the [OCI Image Spec](https://github.com/opencontainers/image-spec/blob/v1.0.2/image-index.md).
+
+Compose uses this attribute to determine which version of the image is pulled
+and/or on which platform the service’s build is performed.
+
+```yml
+platform: darwin
+platform: windows/amd64
+platform: linux/arm64/v8
+```
+
+### ports
+
+Exposes container ports.
+
+> **Note**
+>
+> Port mapping must not be used with `network_mode: host` otherwise a runtime error occurs.
+
+#### Short syntax
+
+The short syntax is a colon-separated string to set the host IP, host port, and container port
+in the form:
+
+`[HOST:]CONTAINER[/PROTOCOL]` where:
+
+- `HOST` is `[IP:](port | range)`
+- `CONTAINER` is `port | range`
+- `PROTOCOL` to restrict port to specified protocol. `tcp` and `udp` values are defined by the Specification,
+ Compose offers support for platform-specific protocol names.
+
+If host IP is not set, it binds to all network interfaces. Ports can be either a single
+value or a range. Host and container must use equivalent ranges.
+
+Either specify both ports (`HOST:CONTAINER`), or just the container port. In the latter case,
+Compose automatically allocates any unassigned port of the host.
+
+`HOST:CONTAINER` should always be specified as a (quoted) string, to avoid conflicts
+with [yaml base-60 float](https://yaml.org/type/float.html).
+
+Examples:
+
+```yml
+ports:
+ - "3000"
+ - "3000-3005"
+ - "8000:8000"
+ - "9090-9091:8080-8081"
+ - "49100:22"
+ - "8000-9000:80"
+ - "127.0.0.1:8001:8001"
+ - "127.0.0.1:5000-5010:5000-5010"
+ - "6060:6060/udp"
+```
+
+> **Note**
+>
+> If Host IP mapping is not supported by a container engine, Compose rejects
+> the Compose file and ignores the specified host IP.
+
+#### Long syntax
+
+The long form syntax allows the configuration of additional fields that can't be
+expressed in the short form.
+
+- `target`: The container port
+- `published`: The publicly exposed port. It is defined as a string and can be set as a range using syntax `start-end`. It means the actual port is assigned a remaining available port, within the set range.
+- `host_ip`: The Host IP mapping, unspecified means all network interfaces (`0.0.0.0`).
+- `protocol`: The port protocol (`tcp` or `udp`), unspecified means any protocol.
+- `mode`: `host`: For publishing a host port on each node, or `ingress` for a port to be load balanced.
+
+```yml
+ports:
+ - target: 80
+ host_ip: 127.0.0.1
+ published: "8080"
+ protocol: tcp
+ mode: host
+
+ - target: 80
+ host_ip: 127.0.0.1
+ published: "8000-9000"
+ protocol: tcp
+ mode: host
+```
+
+### privileged
+
+`privileged` configures the service container to run with elevated privileges. Support and actual impacts are platform specific.
+
+### profiles
+
+`profiles` defines a list of named profiles for the service to be enabled under. If unassigned, the service is always started but if assigned, it is only started if the profile is activated.
+
+If present, `profiles` follow the regex format of `[a-zA-Z0-9][a-zA-Z0-9_.-]+`.
+
+```yaml
+services:
+ frontend:
+ image: frontend
+ profiles: ["frontend"]
+
+ phpmyadmin:
+ image: phpmyadmin
+ depends_on:
+ - db
+ profiles:
+ - debug
+```
+
+### pull_policy
+
+`pull_policy` defines the decisions Compose makes when it starts to pull images. Possible values are:
+
+* `always`: Compose always pulls the image from the registry.
+* `never`: Compose doesn't pull the image from a registry and relies on the platform cached image.
+ If there is no cached image, a failure is reported.
+* `missing`: Compose pulls the image only if it's not available in the platform cache.
+ This is the default option if you are not also using the [Compose Build Specification](build.md).
+ `if_not_present` is considered an alias for this value for backward compatibility.
+* `build`: Compose builds the image. Compose rebuilds the image if it's already present.
+
+If `pull_policy` and `build` are both present, Compose builds the image by default. This behavior may be overridden in the toolchain, depending on the implementation.
+
+### read_only
+
+`read_only` configures the service container to be created with a read-only filesystem.
+
+### restart
+
+`restart` defines the policy that the platform applies on container termination.
+
+- `no`: The default restart policy. It does not restart the container under any circumstances.
+- `always`: The policy always restarts the container until its removal.
+- `on-failure`: The policy restarts the container if the exit code indicates an error.
+- `unless-stopped`: The policy restarts the container irrespective of the exit code but stops
+ restarting when the service is stopped or removed.
+
+```yml
+ restart: "no"
+ restart: always
+ restart: on-failure
+ restart: unless-stopped
+```
+
+### runtime
+
+`runtime` specifies which runtime to use for the service’s containers.
+
+The value of `runtime` is specific to the implementation.
+For example, `runtime` can be the name of [an implementation of OCI Runtime Spec](https://github.com/opencontainers/runtime-spec/blob/master/implementations.md), such as "runc".
+
+```yml
+web:
+ image: busybox:latest
+ command: true
+ runtime: runc
+```
+
+### scale
+
+_DEPRECATED: use [deploy/replicas](deploy.md#replicas)_
+
+`scale` specifies the default number of containers to deploy for this service.
+
+### secrets
+
+`secrets` grants access to sensitive data defined by [secrets](09-secrets.md) on a per-service basis. Two
+different syntax variants are supported; the short syntax and the long syntax.
+
+Compose reports an error if the secret doesn't exist on the platform or isn't defined in the
+[`secrets`](09-secrets.md) section of the Compose file.
+
+Services can be granted access to multiple secrets. Long and short syntax for secrets may be used in the
+same Compose file. Defining a secret in the top-level `secrets` must not imply granting any service access to it.
+Such grant must be explicit within service specification as [secrets](09-secrets.md) service element.
+
+#### Short syntax
+
+The short syntax variant only specifies the secret name. This grants the
+container access to the secret and mounts it as read-only to `/run/secrets/`
+within the container. The source name and destination mountpoint are both set
+to the secret name.
+
+The following example uses the short syntax to grant the `frontend` service
+access to the `server-certificate` secret. The value of `server-certificate` is set
+to the contents of the file `./server.cert`.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ secrets:
+ - server-certificate
+secrets:
+ server-certificate:
+ file: ./server.cert
+```
+
+#### Long syntax
+
+The long syntax provides more granularity in how the secret is created within
+the service's containers.
+
+- `source`: The name of the secret as it exists on the platform.
+- `target`: The name of the file to be mounted in `/run/secrets/` in the
+ service's task container, or absolute path of the file if an alternate location is required. Defaults to `source` if not specified.
+- `uid` and `gid`: The numeric UID or GID that owns the file within
+ `/run/secrets/` in the service's task containers. Default value is USER running container.
+- `mode`: The [permissions](https://wintelguy.com/permissions-calc.pl) for the file to be mounted in `/run/secrets/`
+ in the service's task containers, in octal notation.
+ The default value is world-readable permissions (mode `0444`).
+ The writable bit must be ignored if set. The executable bit may be set.
+
+Note that the `uid`, `gid`, and `mode` attributes are implementation specific.
+
+The following example sets the name of the `server-certificate` secret file to `server.crt`
+within the container, sets the mode to `0440` (group-readable), and sets the user and group
+to `103`. The value of `server-certificate` secret is provided by the platform through a lookup and
+the secret's lifecycle is not directly managed by Compose.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ secrets:
+ - source: server-certificate
+ target: server.cert
+ uid: "103"
+ gid: "103"
+ mode: 0440
+secrets:
+ server-certificate:
+ external: true
+```
+
+### security_opt
+
+`security_opt` overrides the default labeling scheme for each container.
+
+```yml
+security_opt:
+ - label:user:USER
+ - label:role:ROLE
+```
+
+### shm_size
+
+`shm_size` configures the size of the shared memory (`/dev/shm` partition on Linux) allowed by the service container.
+It's specified as a [byte value](11-extension.md#specifying-byte-values).
+
+### stdin_open
+
+`stdin_open` configures a service containers to run with an allocated stdin.
+
+### stop_grace_period
+
+`stop_grace_period` specifies how long Compose must wait when attempting to stop a container if it doesn't
+handle SIGTERM (or whichever stop signal has been specified with
+[`stop_signal`](#stop_signal)), before sending SIGKILL. It's specified
+as a [duration](11-extension.md#specifying-durations).
+
+```yml
+ stop_grace_period: 1s
+ stop_grace_period: 1m30s
+```
+
+Default value is 10 seconds for the container to exit before sending SIGKILL.
+
+### stop_signal
+
+`stop_signal` defines the signal that Compose uses to stop the service containers.
+If unset containers are stopped by Compose by sending `SIGTERM`.
+
+```yml
+stop_signal: SIGUSR1
+```
+
+### storage_opt
+
+`storage_opt` defines storage driver options for a service.
+
+```yml
+storage_opt:
+ size: '1G'
+```
+
+### sysctls
+
+`sysctls` defines kernel parameters to set in the container. `sysctls` can use either an array or a map.
+
+```yml
+sysctls:
+ net.core.somaxconn: 1024
+ net.ipv4.tcp_syncookies: 0
+```
+
+```yml
+sysctls:
+ - net.core.somaxconn=1024
+ - net.ipv4.tcp_syncookies=0
+```
+
+You can only use sysctls that are namespaced in the kernel. Docker does not
+support changing sysctls inside a container that also modify the host system.
+For an overview of supported sysctls, refer to [configure namespaced kernel
+parameters (sysctls) at runtime](https://docs.docker.com/engine/reference/commandline/run/#sysctl).
+
+### tmpfs
+
+`tmpfs` mounts a temporary file system inside the container. It can be a single value or a list.
+
+```yml
+tmpfs: /run
+```
+
+```yml
+tmpfs:
+ - /run
+ - /tmp
+```
+
+### tty
+
+`tty` configures service container to run with a TTY.
+
+### ulimits
+
+`ulimits` overrides the default ulimits for a container. It's specified either as an integer for a single limit
+or as mapping for soft/hard limits.
+
+```yml
+ulimits:
+ nproc: 65535
+ nofile:
+ soft: 20000
+ hard: 40000
+```
+
+### user
+
+`user` overrides the user used to run the container process. The default is set by the image (i.e. Dockerfile `USER`). If it's not set, then `root`.
+
+### userns_mode
+
+`userns_mode` sets the user namespace for the service. Supported values are platform specific and may depend
+on platform configuration.
+
+```yml
+userns_mode: "host"
+```
+
+### volumes
+
+`volumes` define mount host paths or named volumes that are accessible by service containers. You can use `volumes` to define multiple types of mounts; `volume`, `bind`, `tmpfs`, or `npipe`.
+
+If the mount is a host path and is only used by a single service, it can be declared as part of the service
+definition. To reuse a volume across multiple services, a named
+volume must be declared in the [top-level `volumes` key](07-volumes.md).
+
+The following example shows a named volume (`db-data`) being used by the `backend` service,
+and a bind mount defined for a single service.
+
+```yml
+services:
+ backend:
+ image: awesome/backend
+ volumes:
+ - type: volume
+ source: db-data
+ target: /data
+ volume:
+ nocopy: true
+ - type: bind
+ source: /var/run/postgres/postgres.sock
+ target: /var/run/postgres/postgres.sock
+
+volumes:
+ db-data:
+```
+
+#### Short syntax
+
+The short syntax uses a single string with colon-separated values to specify a volume mount
+(`VOLUME:CONTAINER_PATH`), or an access mode (`VOLUME:CONTAINER_PATH:ACCESS_MODE`).
+
+- `VOLUME`: Can be either a host path on the platform hosting containers (bind mount) or a volume name.
+- `CONTAINER_PATH`: The path in the container where the volume is mounted.
+- `ACCESS_MODE`: A comma-separated `,` list of options:
+ - `rw`: Read and write access. This is the default if none is specified.
+ - `ro`: Read-only access.
+ - `z`: SELinux option indicating that the bind mount host content is shared among multiple containers.
+ - `Z`: SELinux option indicating that the bind mount host content is private and unshared for other containers.
+
+> **Note**
+>
+> The SELinux re-labeling bind mount option is ignored on platforms without SELinux.
+
+> **Note**
+> Relative host paths are only supported by Compose that deploy to a
+> local container runtime. This is because the relative path is resolved from the Compose file’s parent
+> directory which is only applicable in the local case. When Compose deploys to a non-local
+> platform it rejects Compose files which use relative host paths with an error. To avoid ambiguities
+> with named volumes, relative paths should always begin with `.` or `..`.
+
+#### Long syntax
+
+The long form syntax allows the configuration of additional fields that can't be
+expressed in the short form.
+
+- `type`: The mount type. Either `volume`, `bind`, `tmpfs`, `npipe`, or `cluster`
+- `source`: The source of the mount, a path on the host for a bind mount, or the
+ name of a volume defined in the
+ [top-level `volumes` key](07-volumes.md). Not applicable for a tmpfs mount.
+- `target`: The path in the container where the volume is mounted.
+- `read_only`: Flag to set the volume as read-only.
+- `bind`: Used to configure additional bind options:
+ - `propagation`: The propagation mode used for the bind.
+ - `create_host_path`: Creates a directory at the source path on host if there is nothing present.
+ Compose does nothing if there is something present at the path. This is automatically implied by short syntax
+ for backward compatibility with `docker-compose` legacy.
+ - `selinux`: The SELinux re-labeling option `z` (shared) or `Z` (private)
+- `volume`: Configures additional volume options:
+ - `nocopy`: Flag to disable copying of data from a container when a volume is created.
+- `tmpfs`: Configures additional tmpfs options:
+ - `size`: The size for the tmpfs mount in bytes (either numeric or as bytes unit).
+ - `mode`: The file mode for the tmpfs mount as Unix permission bits as an octal number.
+- `consistency`: The consistency requirements of the mount. Available values are platform specific.
+
+### volumes_from
+
+`volumes_from` mounts all of the volumes from another service or container. You can optionally specify
+read-only access `ro` or read-write `rw`. If no access level is specified, then read-write access is used.
+
+You can also mount volumes from a container that is not managed by Compose by using the `container:` prefix.
+
+```yaml
+volumes_from:
+ - service_name
+ - service_name:ro
+ - container:container_name
+ - container:container_name:rw
+```
+
+### working_dir
+
+`working_dir` overrides the container's working directory which is specified by the image, for example Dockerfile's `WORKDIR`.
diff --git a/_vendor/github.com/compose-spec/compose-spec/06-networks.md b/_vendor/github.com/compose-spec/compose-spec/06-networks.md
new file mode 100644
index 0000000000..2c167c52f0
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/06-networks.md
@@ -0,0 +1,249 @@
+## Networks top-level element
+
+Networks are the layer that allow services to communicate with each other.
+
+The top-level `networks` element lets you configure named networks that can be reused across multiple services. To use a network across multiple services, you must explicitly grant each service access by using the [networks](05-services.md) attribute. The `networks` top-level element has additional syntax that provides more granular control.
+
+### Examples
+
+#### Basic example
+
+In the following example, at runtime, networks `front-tier` and `back-tier` are created and the `frontend` service
+is connected to `front-tier` and `back-tier` networks.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ networks:
+ - front-tier
+ - back-tier
+
+networks:
+ front-tier:
+ back-tier:
+```
+
+#### Advanced example
+
+```yml
+services:
+ proxy:
+ build: ./proxy
+ networks:
+ - frontend
+ app:
+ build: ./app
+ networks:
+ - frontend
+ - backend
+ db:
+ image: postgres
+ networks:
+ - backend
+
+networks:
+ frontend:
+ # Use a custom driver
+ driver: custom-driver-1
+ backend:
+ # Use a custom driver which takes special options
+ driver: custom-driver-2
+ driver_opts:
+ foo: "1"
+ bar: "2"
+```
+
+The advanced example shows a Compose file which defines two custom networks. The `proxy` service is isolated from the `db` service, because they do not share a network in common. Only `app` can talk to both.
+
+### Attributes
+#### driver
+
+`driver` specifies which driver should be used for this network. Compose returns an error if the
+driver is not available on the platform.
+
+```yml
+volumes:
+ db-data:
+ driver: overlay
+```
+
+Default and available values are platform specific. Compose supports the following drivers:
+`none` and `host`
+
+- `host`: Use the host's networking stack.
+- `none`: Turn off networking.
+
+##### host or none
+
+The syntax for using built-in networks such as `host` and `none` is different, as such networks implicitly exist outside
+the scope of Compose. To use them, you must define an external network with the name `host` or `none` and
+an alias that Compose can use (`hostnet` and `nonet` in the following example), then grant the service
+access to that network using its alias.
+
+```yml
+services:
+ web:
+ networks:
+ hostnet: {}
+
+networks:
+ hostnet:
+ external: true
+ name: host
+```
+
+```yml
+services:
+ web:
+ ...
+ networks:
+ nonet: {}
+
+networks:
+ nonet:
+ external: true
+ name: none
+```
+
+#### driver_opts
+
+`driver_opts` specifies a list of options as key-value pairs to pass to the driver. These options are
+driver-dependent. Consult the driver's documentation for more information.
+
+```yml
+networks:
+ db-data:
+ driver_opts:
+ foo: "bar"
+ baz: 1
+```
+
+#### attachable
+
+If `attachable` is set to `true`, then standalone containers should be able to attach to this network, in addition to services.
+If a standalone container attaches to the network, it can communicate with services and other standalone containers
+that are also attached to the network.
+
+```yml
+networks:
+ mynet1:
+ driver: overlay
+ attachable: true
+```
+
+#### enable_ipv6
+
+`enable_ipv6` enables IPv6 networking.
+
+### external
+
+If set to `true`:
+ - `external` specifies that this network’s lifecycle is maintained outside of that of the application.
+Compose doesn't attempt to create these networks, and returns an error if one doesn't exist.
+ - All other attributes apart from name are irrelevant. If Compose detects any other attribute, it rejects the Compose file as invalid.
+
+In the example below, `proxy` is the gateway to the outside world. Instead of attempting to create a network, Compose
+queries the platform for an existing network simply called `outside` and connects the
+`proxy` service's containers to it.
+
+```yml
+
+services:
+ proxy:
+ image: awesome/proxy
+ networks:
+ - outside
+ - default
+ app:
+ image: awesome/app
+ networks:
+ - default
+
+networks:
+ outside:
+ external: true
+```
+
+#### ipam
+
+`ipam` specifies a custom IPAM configuration. This is an object with several properties, each of which is optional:
+
+- `driver`: Custom IPAM driver, instead of the default.
+- `config`: A list with zero or more configuration elements, each containing a:
+ - `subnet`: Subnet in CIDR format that represents a network segment
+ - `ip_range`: Range of IPs from which to allocate container IPs
+ - `gateway`: IPv4 or IPv6 gateway for the master subnet
+ - `aux_addresses`: Auxiliary IPv4 or IPv6 addresses used by Network driver, as a mapping from hostname to IP
+- `options`: Driver-specific options as a key-value mapping.
+
+```yml
+networks:
+ mynet1:
+ ipam:
+ driver: default
+ config:
+ - subnet: 172.28.0.0/16
+ ip_range: 172.28.5.0/24
+ gateway: 172.28.5.254
+ aux_addresses:
+ host1: 172.28.1.5
+ host2: 172.28.1.6
+ host3: 172.28.1.7
+ options:
+ foo: bar
+ baz: "0"
+```
+
+### internal
+
+By default, Compose provides external connectivity to networks. `internal`, when set to `true`, allows you to
+create an externally isolated network.
+
+### labels
+
+Add metadata to containers using `labels`. You can use either an array or a dictionary.
+
+It is recommended that you use reverse-DNS notation to prevent labels from conflicting with those used by other software.
+
+```yml
+networks:
+ mynet1:
+ labels:
+ com.example.description: "Financial transaction network"
+ com.example.department: "Finance"
+ com.example.label-with-empty-value: ""
+```
+
+```yml
+networks:
+ mynet1:
+ labels:
+ - "com.example.description=Financial transaction network"
+ - "com.example.department=Finance"
+ - "com.example.label-with-empty-value"
+```
+
+Compose sets `com.docker.compose.project` and `com.docker.compose.network` labels.
+
+### name
+
+`name` sets a custom name for the network. The name field can be used to reference networks which contain special characters.
+The name is used as is and is not scoped with the project name.
+
+```yml
+networks:
+ network1:
+ name: my-app-net
+```
+
+It can also be used in conjunction with the `external` property to define the platform network that Compose
+should retrieve, typically by using a parameter so the Compose file doesn't need to hard-code runtime specific values:
+
+```yml
+networks:
+ network1:
+ external: true
+ name: "${NETWORK_ID}"
+```
+
diff --git a/_vendor/github.com/compose-spec/compose-spec/07-volumes.md b/_vendor/github.com/compose-spec/compose-spec/07-volumes.md
new file mode 100644
index 0000000000..e4de39fc91
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/07-volumes.md
@@ -0,0 +1,140 @@
+## Volumes top-level element
+
+Volumes are persistent data stores implemented by the container engine. Compose offers a neutral way for services to mount volumes, and configuration parameters to allocate them to infrastructure.
+
+The top-level `volumes` declaration lets you configure named volumes that can be reused across multiple services. To use a volume across multiple services, you must explicitly grant each service access by using the [volumes](05-services.md) attribute. The `volumes` attribute has additional syntax that provides more granular control.
+
+### Example
+
+The following example shows a two-service setup where a database's data directory is shared with another service as a volume, named
+`db-data`, so that it can be periodically backed up.
+
+```yml
+services:
+ backend:
+ image: awesome/database
+ volumes:
+ - db-data:/etc/data
+
+ backup:
+ image: backup-service
+ volumes:
+ - db-data:/var/lib/backup/data
+
+volumes:
+ db-data:
+```
+
+The `db-data` volume is mounted at the `/var/lib/backup/data` and `/etc/data` container paths for backup and backend respectively.
+
+Running `docker compose up` creates the volume if it doesn't already exist. Otherwise, the existing volume is used and is recreated if it's manually deleted outside of Compose.
+
+### Attributes
+
+An entry under the top-level `volumes` section can be empty, in which case it uses the container engine's default configuration for
+creating a volume. Optionally, you can configure it with the following keys:
+
+#### driver
+
+Specifies which volume driver should be used. Default and available values are platform specific. If the driver is not available, Compose returns an error and doesn't deploy the application.
+
+```yml
+volumes:
+ db-data:
+ driver: foobar
+```
+
+#### driver_opts
+
+`driver_opts` specifies a list of options as key-value pairs to pass to the driver for this volume. The options are driver-dependent.
+
+```yml
+volumes:
+ example:
+ driver_opts:
+ type: "nfs"
+ o: "addr=10.40.0.199,nolock,soft,rw"
+ device: ":/docker/example"
+```
+
+#### external
+
+If set to `true`:
+ - `external` specifies that this volume already exists on the platform and its lifecycle is managed outside
+of that of the application. Compose doesn't then create the volume, and returns an error if the volume doesn't exist.
+ - All other attributes apart from `name` are irrelevant. If Compose detects any other attribute, it rejects the Compose file as invalid.
+
+In the example below, instead of attempting to create a volume called
+`{project_name}_db-data`, Compose looks for an existing volume simply
+called `db-data` and mounts it into the `backend` service's containers.
+
+```yml
+services:
+ backend:
+ image: awesome/database
+ volumes:
+ - db-data:/etc/data
+
+volumes:
+ db-data:
+ external: true
+```
+
+#### labels
+
+`labels` are used to add metadata to volumes. You can use either an array or a dictionary.
+
+It's recommended that you use reverse-DNS notation to prevent your labels from conflicting with those used by other software.
+
+```yml
+volumes:
+ db-data:
+ labels:
+ com.example.description: "Database volume"
+ com.example.department: "IT/Ops"
+ com.example.label-with-empty-value: ""
+```
+
+```yml
+volumes:
+ db-data:
+ labels:
+ - "com.example.description=Database volume"
+ - "com.example.department=IT/Ops"
+ - "com.example.label-with-empty-value"
+```
+
+Compose sets `com.docker.compose.project` and `com.docker.compose.volume` labels.
+
+#### name
+
+`name` sets a custom name for a volume. The name field can be used to reference volumes that contain special
+characters. The name is used as is and is not scoped with the stack name.
+
+```yml
+volumes:
+ data:
+ name: "my-app-data"
+```
+
+This makes it possible to make this lookup name a parameter of the Compose file, so that the model ID for the volume is hard-coded but the actual volume ID on the platform is set at runtime during deployment.
+
+For example, if `DATABASE_VOLUME=my_volume_001` in your `.env` file:
+
+```yml
+volumes:
+ db-data:
+ name: ${DATABASE_VOLUME}
+```
+
+Running `docker compose up` uses the volume called `my_volume_001`.
+
+It can also be used in conjunction with the `external` property. This means the name of the volume used to lookup the actual volume on the platform is set separately from the name used to refer to it within the Compose file:
+
+```yml
+volumes:
+ db-data:
+ external:
+ name: actual-name-of-volume
+```
+
diff --git a/_vendor/github.com/compose-spec/compose-spec/08-configs.md b/_vendor/github.com/compose-spec/compose-spec/08-configs.md
new file mode 100644
index 0000000000..8a6e501322
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/08-configs.md
@@ -0,0 +1,60 @@
+## Configs top-level element
+
+Configs allow services to adapt their behaviour without the need to rebuild a Docker image.
+
+Services can only access configs when explicitly granted by a [`configs`](05-services.md#configs) attribute.
+
+As with volumes, configs are mounted as files into a service's container's filesystem. The location of the mount point within the container defaults to `/` in Linux containers and `C:\` in Windows containers.
+
+By default, the config:
+- Is owned by the user running the container command but can be overridden by service configuration.
+- Has world-readable permissions (mode 0444), unless the service is configured to override this.
+
+The top-level `configs` declaration defines or references configuration data that is granted to services in your Compose application. The source of the config is either `file` or `external`.
+
+- `file`: The config is created with the contents of the file at the specified path.
+- `external`: If set to true, `external` specifies that this config has already been created. Compose does not
+ attempt to create it, and if it does not exist, an error occurs.
+- `name`: The name of the config object in the container engine to look up. This field can be used to
+ reference configs that contain special characters. The name is used as is
+ and will **not** be scoped with the project name.
+
+### Example 1
+
+`_http_config` is created when the application is deployed,
+by registering the content of the `httpd.conf` as the configuration data.
+
+```yml
+configs:
+ http_config:
+ file: ./httpd.conf
+```
+
+Alternatively, `http_config` can be declared as external. Compose looks up `http_config` to expose the configuration data to relevant services.
+
+```yml
+configs:
+ http_config:
+ external: true
+```
+
+### Example 2
+
+External configs lookup can also use a distinct key by specifying a `name`.
+
+The following
+example modifies the previous one to look up a config using the parameter `HTTP_CONFIG_KEY`. The
+the actual lookup key will is set at deployment time by the [interpolation](12-interpolation.md) of
+variables, but exposed to containers as hard-coded ID `http_config`.
+
+```yml
+configs:
+ http_config:
+ external: true
+ name: "${HTTP_CONFIG_KEY}"
+```
+
+If `external` is set to `true`, all other attributes apart from `name` are irrelevant. If Compose detecs any other attribute, it rejects the Compose file as invalid.
+
+Your Compose file needs to explicitly grant access to the configs to relevant services in your application.
+
diff --git a/_vendor/github.com/compose-spec/compose-spec/09-secrets.md b/_vendor/github.com/compose-spec/compose-spec/09-secrets.md
new file mode 100644
index 0000000000..258c9d3886
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/09-secrets.md
@@ -0,0 +1,65 @@
+## Secrets top-level element
+
+Secrets are a flavor of [Configs](08-configs.md) focusing on sensitive data, with specific constraint for this usage.
+
+Services can only access secrets when explicitly granted by a [`secrets`](05-services.md#secrets) attribute.
+
+The top-level `secrets` declaration defines or references sensitive data that is granted to the services in your Compose
+application. The source of the secret is either `file` or `environment`.
+
+- `file`: The secret is created with the contents of the file at the specified path.
+- `environment`: The secret is created with the value of an environment variable.
+- `external`: If set to true, `external` specifies that this secret has already been created. Compose does
+ not attempt to create it, and if it does not exist, an error occurs.
+- `name`: The name of the secret object in Docker. This field can be used to
+ reference secrets that contain special characters. The name is used as is
+ and isn't scoped with the project name.
+
+### Example 1
+
+`server-certificate` secret is created as `_server-certificate` when the application is deployed,
+by registering content of the `server.cert` as a platform secret.
+
+```yml
+secrets:
+ server-certificate:
+ file: ./server.cert
+```
+
+### Example 2
+
+`token` secret is created as `_token` when the application is deployed,
+by registering the content of the `OAUTH_TOKEN` environment variable as a platform secret.
+
+```yml
+secrets:
+ token:
+ environment: "OAUTH_TOKEN"
+```
+
+Alternatively, `server-certificate` can be declared as external. Compose looks up the `server-certificate` secret to expose to relevant services.
+
+```yml
+secrets:
+ server-certificate:
+ external: true
+```
+
+### Example 3
+
+External secrets lookup can also use a distinct key by specifying a `name`.
+
+The following example modifies the previous example to look up a secret using the name `CERTIFICATE_KEY`. The
+the actual lookup key is set at deployment time by the [interpolation](12-interpolation.md) of
+variables, but exposed to containers as hard-coded ID `server-certificate`.
+
+```yml
+secrets:
+ server-certificate:
+ external: true
+ name: "${CERTIFICATE_KEY}"
+```
+
+If `external` is set to `true`, all other attributes apart from `name` are irrelevant. If Compose detects any other attribute, it rejects the Compose file as invalid.
+
+Your Compose file needs to explicitly grant access to the secrets to relevant services in your application.
diff --git a/_vendor/github.com/compose-spec/compose-spec/10-fragments.md b/_vendor/github.com/compose-spec/compose-spec/10-fragments.md
new file mode 100644
index 0000000000..8d2cfb85dd
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/10-fragments.md
@@ -0,0 +1,85 @@
+## Fragments
+
+With Compose, you can use built-in [YAML](https://www.yaml.org/spec/1.2/spec.html#id2765878) features to make your Compose file neater and more efficient. Anchors and aliases let you create re-usable blocks. This is useful if you start to find common configurations that span multiple services. Having re-usable blocks minimizes potential mistakes.
+
+Anchors are created using the `&` sign. The sign is followed by an alias name. You can use this alias with the `*` sign later to reference the value following the anchor. Make sure there is no space between the `&` and the `*` characters and the following alias name.
+
+You can use more than one anchor and alias in a single Compose file.
+
+### Example 1
+
+```yml
+volumes:
+ db-data: &default-volume
+ driver: default
+ metrics: *default-volume
+```
+
+In the example above, a `default-volume` anchor is created based on the `db-data` volume. It is later reused by the alias `*default-volume` to define the `metrics` volume.
+
+Anchor resolution takes place before [variables interpolation](12-interpolation.md), so variables can't be used to set anchors or aliases.
+
+### Example 2
+
+```yml
+services:
+ first:
+ image: my-image:latest
+ environment: &env
+ - CONFIG_KEY
+ - EXAMPLE_KEY
+ - DEMO_VAR
+ second:
+ image: another-image:latest
+ environment: *env
+```
+
+If you have an anchor that you want to use in more than one service, use it in conjunction with an [extension](11-extension.md) to make your Compose file easier to maintain.
+
+### Example 3
+
+You may want to partially override values. Compose follows the rule outlined by [YAML merge type](https://yaml.org/type/merge.html).
+
+In the following example, `metrics` volume specification uses alias
+to avoid repetition but overrides `name` attribute:
+
+```yml
+
+services:
+ backend:
+ image: awesome/database
+ volumes:
+ - db-data
+ - metrics
+volumes:
+ db-data: &default-volume
+ driver: default
+ name: "data"
+ metrics:
+ <<: *default-volume
+ name: "metrics"
+```
+
+### Example 4
+
+You can also extend the anchor to add additional values.
+
+```yml
+services:
+ first:
+ image: my-image:latest
+ environment: &env
+ FOO: BAR
+ ZOT: QUIX
+ second:
+ image: another-image:latest
+ environment:
+ <<: *env
+ YET_ANOTHER: VARIABLE
+```
+
+> **Note**
+>
+> [YAML merge](https://yaml.org/type/merge.html) only applies to mappings, and can't be used with sequences.
+
+In example above, the environment variables must be declared using the `FOO: BAR` mapping syntax, while the sequence syntax `- FOO=BAR` is only valid when no fragments are involved.
diff --git a/_vendor/github.com/compose-spec/compose-spec/11-extension.md b/_vendor/github.com/compose-spec/compose-spec/11-extension.md
new file mode 100644
index 0000000000..4cba725126
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/11-extension.md
@@ -0,0 +1,149 @@
+## Extension
+
+As with [Fragments](10-fragments.md), Extensions can be used to make your Compose file more efficient and easier to maintain. Extensions can also be used with [anchors and aliases](10-fragments.md).
+
+Use the prefix `x-` on any top-level element to modularize configurations that you want to reuse. They can be used
+within any structure in a Compose file as Compose ignores any fields that start with `x-`. This is the sole exception where Compose silently ignores unrecognized fields.
+
+The contents of any `x-` section is unspecified by the Compose specification, so it can be used to enable custom features. If Compose encounters an unknown extension field it doesn't fail and may warn you about the unknown field.
+
+### Example 1
+
+```yml
+x-custom:
+ foo:
+ - bar
+ - zot
+
+services:
+ webapp:
+ image: awesome/webapp
+ x-foo: bar
+```
+
+For platform extensions, it's highly recommended that you prefix extensions by platform or vendor name, the same way browsers add
+support for [custom CSS features](https://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#vendor-keywords)
+
+```yml
+service:
+ backend:
+ deploy:
+ placement:
+ x-aws-role: "arn:aws:iam::XXXXXXXXXXXX:role/foo"
+ x-aws-region: "eu-west-3"
+ x-azure-region: "france-central"
+```
+
+### Example 2
+
+```yml
+x-env: &env
+ environment:
+ - CONFIG_KEY
+ - EXAMPLE_KEY
+
+services:
+ first:
+ <<: *env
+ image: my-image:latest
+ second:
+ <<: *env
+ image: another-image:latest
+```
+
+In this example, the environment variables do not belong to either of the services. They’ve been lifted out completely into the `x-env` extension field.
+This defines a new node which contains the environment field. The `&env` YAML anchor is used so both services can reference the extension field’s value as `*env`.
+
+### Example 3
+
+```yml
+x-function: &function
+ labels:
+ function: "true"
+ depends_on:
+ - gateway
+ networks:
+ - functions
+ deploy:
+ placement:
+ constraints:
+ - 'node.platform.os == linux'
+services:
+ # Node.js gives OS info about the node (Host)
+ nodeinfo:
+ <<: *function
+ image: functions/nodeinfo:latest
+ environment:
+ no_proxy: "gateway"
+ https_proxy: $https_proxy
+ # Uses `cat` to echo back response, fastest function to execute.
+ echoit:
+ <<: *function
+ image: functions/alpine:health
+ environment:
+ fprocess: "cat"
+ no_proxy: "gateway"
+ https_proxy: $https_proxy
+```
+
+The `nodeinfo` and `echoit` services both include the `x-function` extension via the `&function` anchor, then set their specific image and environment.
+
+### Example 4
+
+Using [YAML merge](https://yaml.org/type/merge.html) it is also possible to use multiple extensions and share
+and override additional attributes for specific needs:
+
+```yml
+x-environment: &default-environment
+ FOO: BAR
+ ZOT: QUIX
+x-keys: &keys
+ KEY: VALUE
+services:
+ frontend:
+ image: awesome/webapp
+ environment:
+ << : [*default-environment, *keys]
+ YET_ANOTHER: VARIABLE
+```
+
+> **Note**
+>
+> [YAML merge](https://yaml.org/type/merge.html) only applies to mappings, and can't be used with sequences.
+>
+> In the example above, the environment variables are declared using the `FOO: BAR` mapping syntax, while the sequence syntax `- FOO=BAR` is only valid when no fragments are involved.
+
+### Informative Historical Notes
+
+This section is informative. At the time of writing, the following prefixes are known to exist:
+
+| Prefix | Vendor/Organization |
+| ---------- | ------------------- |
+| docker | Docker |
+| kubernetes | Kubernetes |
+
+### Specifying byte values
+
+Values express a byte value as a string in `{amount}{byte unit}` format:
+The supported units are `b` (bytes), `k` or `kb` (kilo bytes), `m` or `mb` (mega bytes) and `g` or `gb` (giga bytes).
+
+```
+ 2b
+ 1024kb
+ 2048k
+ 300m
+ 1gb
+```
+
+### Specifying durations
+
+Values express a duration as a string in the form of `{value}{unit}`.
+The supported units are `us` (microseconds), `ms` (milliseconds), `s` (seconds), `m` (minutes) and `h` (hours).
+Values can combine multiple values without separator.
+
+```
+ 10ms
+ 40s
+ 1m30s
+ 1h5m30s20ms
+```
diff --git a/_vendor/github.com/compose-spec/compose-spec/12-interpolation.md b/_vendor/github.com/compose-spec/compose-spec/12-interpolation.md
new file mode 100644
index 0000000000..266558b207
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/12-interpolation.md
@@ -0,0 +1,61 @@
+## Interpolation
+
+Values in a Compose file can be set by variables and interpolated at runtime. Compose files use a Bash-like
+syntax `${VARIABLE}`.
+
+Both `$VARIABLE` and `${VARIABLE}` syntax is supported. Default values can be defined inline using typical shell syntax:
+
+- `${VARIABLE:-default}` evaluates to `default` if `VARIABLE` is unset or
+ empty in the environment.
+- `${VARIABLE-default}` evaluates to `default` only if `VARIABLE` is unset
+ in the environment.
+
+Similarly, the following syntax allows you to specify mandatory variables:
+
+- `${VARIABLE:?err}` exits with an error message containing `err` if
+ `VARIABLE` is unset or empty in the environment.
+- `${VARIABLE?err}` exits with an error message containing `err` only if
+ `VARIABLE` is unset in the environment.
+
+Interpolation can also be nested:
+
+- `${VARIABLE:-${FOO}}`
+- `${VARIABLE?$FOO}`
+- `${VARIABLE:-${FOO:-default}}`
+
+Other extended shell-style features, such as `${VARIABLE/foo/bar}`, are not
+supported by Compose.
+
+You can use a `$$` (double-dollar sign) when your configuration needs a literal
+dollar sign. This also prevents Compose from interpolating a value, so a `$$`
+allows you to refer to environment variables that you don't want processed by
+Compose.
+
+```yml
+web:
+ build: .
+ command: "$$VAR_NOT_INTERPOLATED_BY_COMPOSE"
+```
+
+If Compose can't resolve a substituted variable and no default value is defined, it displays a warning and substitutes the variable with an empty string.
+
+As any values in a Compose file can be interpolated with variable substitution, including compact string notation
+for complex elements, interpolation is applied before a merge on a per-file basis.
+
+Interpolation applies only to YAML values, not to keys. For the few places where keys are actually arbitrary
+user-defined strings, such as [labels](05-services.md#labels) or [environment](05-services.md#environment), an alternate equal sign syntax
+must be used for interpolation to apply. For example:
+
+```yml
+services:
+ foo:
+ labels:
+ "$VAR_NOT_INTERPOLATED_BY_COMPOSE": "BAR"
+```
+
+```yml
+services:
+ foo:
+ labels:
+ - "$VAR_INTERPOLATED_BY_COMPOSE=BAR"
+```
diff --git a/_vendor/github.com/compose-spec/compose-spec/13-merge.md b/_vendor/github.com/compose-spec/compose-spec/13-merge.md
new file mode 100644
index 0000000000..0c94d1c08e
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/13-merge.md
@@ -0,0 +1,175 @@
+## Merge and override
+
+Compose lets you define a Compose application model through multiple Compose files.
+When doing so, Compose follows the rules declared in this section to merge Compose files.
+
+### Mapping
+
+A YAML `mapping` gets merged by adding missing entries and merging the conflicting ones.
+
+Merging the following example YAML trees:
+```yaml
+services:
+ foo:
+ key1: value1
+ key2: value2
+```
+
+```yaml
+services:
+ foo:
+ key2: VALUE
+ key3: value3
+```
+
+Results in a Compose application model equivalent to the YAML tree:
+
+```yaml
+services:
+ foo:
+ key1: value1
+ key2: VALUE
+ key3: value3
+```
+
+### Sequence
+
+A YAML `sequence` is merged by appending values from the overriding Compose file to the previous one.
+
+Merging the following example YAML trees:
+```yaml
+services:
+ foo:
+ DNS:
+ - 1.1.1.1
+```
+
+```yaml
+services:
+ foo:
+ DNS:
+ - 8.8.8.8
+```
+
+Results in a Compose application model equivalent to the YAML tree:
+
+```yaml
+services:
+ foo:
+ DNS:
+ - 1.1.1.1
+ - 8.8.8.8
+```
+
+## Exceptions
+
+### Shell commands
+
+When merging Compose files that use the services attributes [command](05-services.md#command), [entrypoint](05-services.md#entrypoint) and [healthcheck: `test`](05-services.md#healthcheck), the value is overridden by the latest Compose file, and not appended.
+
+Merging the following example YAML trees:
+```yaml
+services:
+ foo:
+ command: ["echo", "foo"]
+```
+
+```yaml
+services:
+ foo:
+ command: ["echo", "bar"]
+```
+
+Results in a Compose application model equivalent to the YAML tree:
+
+```yaml
+services:
+ foo:
+ DNS:
+ command: ["echo", "bar"]
+```
+
+### Unique resources
+
+Applies to the [ports](05-services.md#ports), [volumes](05-services.md#volumes), [secrets](05-services.md#secrets) and [configs](05-services.md#configs) services attributes.
+While these types are modeled in a Compose file as a sequence, they have special uniqueness requirements:
+
+| Attribute | Unique key |
+|-------------|--------------------------|
+| volumes | target |
+| secrets | source |
+| configs | source |
+| ports | {ip, target, published, protocol} |
+
+When merging Compose files, Compose appends new entries that do not violate a uniqueness constraint and merge entries that share a unique key.
+
+Merging the following example YAML trees:
+```yaml
+services:
+ foo:
+ volumes:
+ - foo:/work
+```
+
+```yaml
+services:
+ foo:
+ volumes:
+ - bar:/work
+```
+
+Results in a Compose application model equivalent to the YAML tree:
+
+```yaml
+services:
+ foo:
+ volumes:
+ - bar:/work
+```
+
+### Reset value
+
+In addition to the previously described mechanism, an override Compose file can also be used to remove elements from your application model.
+For this purpose, the custom [YAML tag](https://yaml.org/spec/1.2.2/#24-tags) `!reset` can be set to
+override a value set by the overriden Compose file. A valid value for attribute must be provided,
+but will be ignored and target attribute will be set with type's default value or `null`.
+
+For readability, it is recommended to explicitly set the attribute value to the null (`null`) or empty
+array `[]` (with `!reset null` or `!reset []`) so that it is clear that resulting attribute will be
+cleared.
+
+Merging the following example YAML trees:
+```yaml
+services:
+ foo:
+ build:
+ dockerfile: foo.Dockerfile
+ read_only: true
+ environment:
+ FOO: BAR
+ ports:
+ - "8080:80"
+```
+
+```yaml
+services:
+ foo:
+ image: foo
+ build: !reset null
+ read_only: !reset false
+ environment:
+ FOO: !reset null
+ ports: !reset []
+```
+
+Result in a Compose application model equivalent to the YAML tree:
+
+```yaml
+services:
+ foo:
+ image: foo
+ build: null
+ read_only: false
+ environment: {}
+ ports: []
+```
diff --git a/_vendor/github.com/compose-spec/compose-spec/14-include.md b/_vendor/github.com/compose-spec/compose-spec/14-include.md
new file mode 100644
index 0000000000..360ea58951
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/14-include.md
@@ -0,0 +1,106 @@
+## Include
+
+A Compose application can declare dependency on another Compose application. This is useful if:
+- You want to reuse other Compose files.
+- You need to factor out parts of your application model into separate Compose files so they can be managed separately or shared with others.
+- Teams need to keep a Compose file reasonably complicated for the limited amount of resources it has to declare for it's own sub-domain, within a larger deployment.
+
+The `include` top-level section is used to define the dependency on another Compose application, or sub-domain.
+Each path listed in the `include` section is loaded as an individual Compose application model, with it's own project directory, in order to resolve relative paths.
+
+Once the included Compose application is loaded, all resources definitions are copied into the
+current Compose application model. Compose displays a warning if resource names conflict and doesn't
+try to merge them. To enforce this, `include` is evaluated after the Compose file(s) selected
+to define the Compose application model have been parsed and merged, so that conflicts
+between Compose files are detected.
+
+`include` applies recursively so an included Compose file which declares its own `include` section, triggers those other files to be included as well.
+
+Any volumes, networks, or other resources pulled in from the included Compose file can be used by the current Compose application for cross-service references. For example:
+
+```yaml
+include:
+ - my-compose-include.yaml #with serviceB declared
+services:
+ serviceA:
+ build: .
+ depends_on:
+ - serviceB #use serviceB directly as if it was declared in this Compose file
+```
+
+Compose also supports the use of interpolated variables with `include`. It's recommended that you [specify mandatory variables](12-interpolation.md). For example:
+
+```
+include:
+ -${INCLUDE_PATH:?FOO}/compose.yaml
+```
+
+### Short syntax
+
+The short syntax only defines paths to other Compose files. The file is loaded with the parent
+folder as the project directory, and an optional `.env` file that is loaded to define any variables' default values
+by interpolation. The local project's environment can override those values.
+
+```yaml
+include:
+ - ../commons/compose.yaml
+ - ../another_domain/compose.yaml
+
+services:
+ webapp:
+ depends_on:
+ - included-service # defined by another_domain
+```
+
+In the above example, both `../commons/compose.yaml` and
+`../another_domain/compose.yaml` are loaded as individual Compose projects. Relative paths
+in Compose files being referred by `include` are resolved relative to their own Compose
+file path, not based on the local project's directory. Variables are interpolated using values set in the optional
+`.env` file in same folder, and is overridden by the local project's environment.
+
+### Long syntax
+
+The long syntax offers more control over the sub-project parsing:
+
+```yaml
+include:
+ - path: ../commons/compose.yaml
+ project_directory: ..
+ env_file: ../another/.env
+```
+
+#### path
+`path` is required and defines the location of the Compose file(s) to be parsed and included into the
+local Compose model. `path` can be set either to a string when a single Compose file is involved,
+or to a list of strings when multiple Compose files need to be [merged together](13-merge.md) to
+define the Compose model to be included in the local application.
+
+```yaml
+include:
+ - path:
+ - ../commons/compose.yaml
+ - ./commons-override.yaml
+```
+
+#### project_directory
+`project_directory` defines a base path to resolve relative paths set in the Compose file. It defaults to
+the directory of the included Compose file.
+
+#### env_file
+`env_file` defines an environment file(s) to use to define default values when interpolating variables
+in the Compose file being parsed. It defaults to `.env` file in the `project_directory` for the Compose
+file being parsed.
+
+`env_file` can be set either to a string or a list of strings when multiple environment files need to be merged
+to define a project environment.
+
+```yaml
+include:
+ - path: ../another/compose.yaml
+ env_file:
+ - ../another/.env
+ - ../another/dev.env
+```
+
+The local project's environment has precedence over the values set by the Compose file, so that the local project can
+override values for customization.
diff --git a/_vendor/github.com/compose-spec/compose-spec/15-profiles.md b/_vendor/github.com/compose-spec/compose-spec/15-profiles.md
new file mode 100644
index 0000000000..e805d87f35
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/15-profiles.md
@@ -0,0 +1,61 @@
+## Profiles
+
+With profiles you can define a set of active profiles so your Compose application model is adjusted for various usages and environments.
+The exact mechanism is implementation specific and may include command line flags, environment variables, etc.
+
+The [services](05-services.md) top-level element supports a `profiles` attribute to define a list of named profiles.
+Services without a `profiles` attribute are always enabled.
+
+A service is ignored by Compose when none of the listed `profiles` match the active ones, unless the service is
+explicitly targeted by a command. In that case its profile is added to the set of active profiles.
+
+>**Note**
+>
+> All other top-level elements are not affected by `profiles` and are always active.
+
+References to other services (by `links`, `extends` or shared resource syntax `service:xxx`) do not
+automatically enable a component that would otherwise have been ignored by active profiles. Instead
+Compose returns an error.
+
+### Illustrative example
+
+```yaml
+services:
+ foo:
+ image: foo
+ bar:
+ image: bar
+ profiles:
+ - test
+ baz:
+ image: baz
+ depends_on:
+ - bar
+ profiles:
+ - test
+ zot:
+ image: zot
+ depends_on:
+ - bar
+ profiles:
+ - debug
+```
+
+In the above example:
+- If the Compose application model is parsed with no profile enabled, it only contains the `foo` service.
+- If the profile `test` is enabled, the model contains the services `bar` and `baz`, and service `foo`, which is always enabled.
+- If the profile `debug` is enabled, the model contains both `foo` and `zot` services, but not `bar` and `baz`,
+ and as such the model is invalid regarding the `depends_on` constraint of `zot`.
+- If the profiles `debug` and `test` are enabled, the model contains all services; `foo`, `bar`, `baz` and `zot`.
+- If Compose is executed with `bar` as the explicit service to run, `bar` and the `test` profile
+ are active even if `test` profile is not enabled.
+- If Compose is executed with `baz` as the explicit service to run, the service `baz` and the
+ profile `test` are active and `bar` is pulled in by the `depends_on` constraint.
+- If Compose is executed with `zot` as the explicit service to run, again the model is
+ invalid regarding the `depends_on` constraint of `zot`, since `zot` and `bar` have no common `profiles`
+ listed.
+- If Compose is executed with `zot` as the explicit service to run and profile `test` is enabled,
+ profile `debug` is automatically enabled and service `bar` is pulled in as a dependency starting both
+ services `zot` and `bar`.
+
+See how you can use `profiles` in [Docker Compose](https://docs.docker.com/compose/profiles/).
diff --git a/_vendor/github.com/compose-spec/compose-spec/build.md b/_vendor/github.com/compose-spec/compose-spec/build.md
new file mode 100644
index 0000000000..d3b22b0200
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/build.md
@@ -0,0 +1,518 @@
+# The Compose Specification - Build support
+{:.no_toc}
+
+*Note:* Build is an optional part of the Compose specification.
+
+* ToC
+{:toc}
+
+## Introduction
+
+The Compose specification is a platform-neutral way to define multi-container applications. A Compose implementation which focuses on running an application on a local machine will obviously need to also support (re)building
+application from source. The Compose Build specification lets developers define the build process within a Compose file
+in a portable way.
+
+## Definitions
+
+Compose Specification can be extended to support an optional `build` subsection on services.
+
+This section defines the build requirements for a service container image. Only a subset of Compose file services can be defined in such a `build`
+subsection, others may make use of the `image` attribute. When a `build` subsection is present for a service, it
+is valid for Compose to miss out the `image` attribute for the corresponding service, as Compose
+can build an image from source.
+
+`build` can be either specified as a single string defining a context path, or as a detailed build definition.
+
+In the former case, the whole path is used as a Docker context to execute a Docker build, looking for a canonical
+`Dockerfile` at the root of the directory. The path can be absolute or relative. If it is relative, it must be resolved
+from the Compose file parent folder. If it is absolute, the path prevents the Compose file from being portable so Compose should warn the users accordingly.
+
+In the later case, build arguments can be specified, including an alternate `Dockerfile` location. The path can be absolute or relative. If it is relative, it must be resolved
+from the Compose file parent folder. If it is absolute, the path prevents the Compose file from being portable so Compose should warn the users accordingly.
+
+## Consistency with `image`
+
+When a service definition includes both the `image` attribute and a `build` section, Compose can't
+guarantee a pulled image is strictly equivalent to building the same image from source. Without any explicit
+user directives, Compose with Build support must first try to pull the image, then build from source
+if the image was not found on registry. Compose may offer options to customize this behaviour by user
+request.
+
+## Publishing built images
+
+Compose with Build support should offer an option to push built images to a registry. When doing so, it must not try to push service images without an `image` attribute. Compose should warn users about the missing `image` attribute which prevents images being pushed.
+
+A Compose implementation may offer a mechanism to compute an `image` attribute for services when not explicitly
+declared in a yaml file. In such cases, the resulting Compose configuration is considered to have a valid `image`
+attribute, whenever the actual raw yaml file doesn't explicitly declare one.
+
+## Illustrative example
+
+The following example illustrates Compose specification concepts with a concrete sample application. The sample is non-normative.
+
+```yaml
+services:
+ frontend:
+ image: awesome/webapp
+ build: ./webapp
+
+ backend:
+ image: awesome/database
+ build:
+ context: backend
+ dockerfile: ../backend.Dockerfile
+
+ custom:
+ build: ~/custom
+```
+
+When used to build service images from source, the Compose file creates three Docker images:
+
+* `awesome/webapp` Docker image is built using `webapp` sub-directory, within the Compose file's parent folder, as the Docker build context. Lack of a `Dockerfile` within this folder throws an error.
+* `awesome/database` Docker image is built using `backend` sub-directory within the Compose file parent folder. `backend.Dockerfile` file is used to define build steps, this file is searched relative to the context path, which means `..` resolves to the Compose file parent folder, so `backend.Dockerfile` is a sibling file.
+* A Docker image is built using the `custom` directory with the user's HOME as the Docker context. Compose warns the user about the non-portable path used to build image.
+
+On push, both `awesome/webapp` and `awesome/database` Docker images are pushed to the default registry. The `custom` service image is skipped as no `image` attribute is set and the user is warned about this missing attribute.
+
+## Build definition
+
+The `build` element defines configuration options that are applied by Compose to build Docker image from source.
+`build` can be specified either as a string containing a path to the build context or as a detailed structure:
+
+Using the string syntax, only the build context can be configured as either:
+- A relative path to the Compose file's parent folder. This path must be a directory and must contain a `Dockerfile`
+
+ ```yml
+ services:
+ webapp:
+ build: ./dir
+ ```
+
+- A git repository URL. Git URLs accept context configuration in their fragment section, separated by a colon (`:`).
+The first part represents the reference that Git checks out, and can be either a branch, a tag, or a remote reference.
+The second part represents a subdirectory inside the repository that is used as a build context.
+
+ ```yml
+ services:
+ webapp:
+ build: https://github.com/mycompany/example.git#branch_or_tag:subdirectory
+ ```
+
+Alternatively `build` can be an object with fields defined as follows:
+
+### context
+
+`context` defines either a path to a directory containing a Dockerfile, or a URL to a git repository.
+
+When the value supplied is a relative path, it must be interpreted as relative to the location of the Compose file.
+Compose warns users about the absolute path used to define the build context as those prevent the Compose file
+from being portable.
+
+```yml
+build:
+ context: ./dir
+```
+
+```yml
+services:
+ webapp:
+ build: https://github.com/mycompany/webapp.git
+```
+
+If not set explicitly, `context` defaults to project directory (`.`).
+
+### dockerfile
+
+`dockerfile` sets an alternate Dockerfile. A relative path must be resolved from the build context.
+Compose warns users about the absolute path used to define the Dockerfile as it prevents Compose files
+from being portable.
+
+When set, `dockerfile_inline` attribute is not allowed and a Compose
+rejects any Compose file having both set.
+
+```yml
+build:
+ context: .
+ dockerfile: webapp.Dockerfile
+```
+
+### dockerfile_inline
+
+`dockerfile_inline` defines Dockerfile content as inlined string in a Compose file. When set, the `dockerfile`
+attribute is not allowed and Compose should reject any Compose file having both set.
+
+Use of YAML multi-line string syntax is recommended to define Dockerfile content:
+
+```yml
+build:
+ context: .
+ dockerfile_inline: |
+ FROM baseimage
+ RUN some command
+```
+
+
+### args
+
+`args` define build arguments, i.e. Dockerfile `ARG` values.
+
+Using the following Dockerfile as an example:
+
+```Dockerfile
+ARG GIT_COMMIT
+RUN echo "Based on commit: $GIT_COMMIT"
+```
+
+`args` can be set in the Compose file under the `build` key to define `GIT_COMMIT`. `args` can be set as a mapping or a list:
+
+```yml
+build:
+ context: .
+ args:
+ GIT_COMMIT: cdc3b19
+```
+
+```yml
+build:
+ context: .
+ args:
+ - GIT_COMMIT=cdc3b19
+```
+
+Values can be omitted when specifying a build argument, in which case its value at build time must be obtained by user interaction,
+otherwise the build arg won't be set when building the Docker image.
+
+```yml
+args:
+ - GIT_COMMIT
+```
+
+### ssh
+
+`ssh` defines SSH authentications that the image builder should use during image build (e.g., cloning private repository).
+
+`ssh` property syntax can be either:
+* `default` - let the builder connect to the ssh-agent.
+* `ID=path` - a key/value definition of an ID and the associated path. Can be either a [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) file, or path to ssh-agent socket.
+
+Simple `default` sample
+```yaml
+build:
+ context: .
+ ssh:
+ - default # mount the default ssh agent
+```
+or
+```yaml
+build:
+ context: .
+ ssh: ["default"] # mount the default ssh agent
+```
+
+Using a custom id `myproject` with path to a local SSH key:
+```yaml
+build:
+ context: .
+ ssh:
+ - myproject=~/.ssh/myproject.pem
+```
+The image builder can then rely on this to mount the SSH key during build.
+For illustration, [BuildKit extended syntax](https://github.com/compose-spec/compose-spec/pull/234/%5Bmoby/buildkit@master/frontend/dockerfile/docs/syntax.md#run---mounttypessh%5D(https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/syntax.md#run---mounttypessh)) can be used to mount the SSH key set by ID and access a secured resource:
+
+`RUN --mount=type=ssh,id=myproject git clone ...`
+
+### cache_from
+
+`cache_from` defines a list of sources the image builder should use for cache resolution.
+
+Cache location syntax must follow the global format `[NAME|type=TYPE[,KEY=VALUE]]`. Simple `NAME` is actually a shortcut notation for `type=registry,ref=NAME`.
+
+Compose Builder implementations may support custom types, the Compose specification defines canonical types which must be supported:
+
+- `registry` to retrieve build cache from an OCI image set by key `ref`
+
+
+```yml
+build:
+ context: .
+ cache_from:
+ - alpine:latest
+ - type=local,src=path/to/cache
+ - type=gha
+```
+
+Unsupported caches must be ignored and not prevent users from building image.
+
+### cache_to
+
+`cache_to` defines a list of export locations to be used to share build cache with future builds.
+
+```yml
+build:
+ context: .
+ cache_to:
+ - user/app:cache
+ - type=local,dest=path/to/cache
+```
+
+Cache target is defined using the same `type=TYPE[,KEY=VALUE]` syntax defined by [`cache_from`](#cache_from).
+
+Unsupported cache target must be ignored and not prevent users from building image.
+
+### additional_contexts
+
+`additional_contexts` defines a list of named contexts the image builder should use during image build.
+
+`additional_contexts` can be a mapping or a list:
+
+```yml
+build:
+ context: .
+ additional_contexts:
+ - resources=/path/to/resources
+ - app=docker-image://my-app:latest
+ - source=https://github.com/myuser/project.git
+```
+
+```yml
+build:
+ context: .
+ additional_contexts:
+ resources: /path/to/resources
+ app: docker-image://my-app:latest
+ source: https://github.com/myuser/project.git
+```
+
+When used as a list, the syntax should follow the `NAME=VALUE` format, where `VALUE` is a string. Validation beyond that
+is the responsibility of the image builder (and is builder specific). Compose supports at least
+absolute and relative paths to a directory AND Git repository URLs, like [context](#context) does. Other context flavours
+must be prefixed to avoid ambiguity with a `type://` prefix.
+
+Compose should warn the user if the image builder does not support additional contexts and may list
+the unused contexts.
+
+Illustrative examples of how this is used in Buildx can be found
+[here](https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#-additional-build-contexts---build-context).
+
+### extra_hosts
+
+`extra_hosts` adds hostname mappings at build-time. Use the same syntax as [extra_hosts](05-services.md#extra_hosts).
+
+```yml
+extra_hosts:
+ - "somehost:162.242.195.82"
+ - "otherhost:50.31.209.229"
+```
+
+Compose creates matching entry with the IP address and hostname in the container's network
+configuration, which means for Linux `/etc/hosts` will get extra lines:
+
+```
+162.242.195.82 somehost
+50.31.209.229 otherhost
+```
+
+### isolation
+
+`isolation` specifies a build’s container isolation technology. Like [isolation](05-services.md#isolation), supported values
+are platform-specific.
+
+### privileged
+
+`privileged` configures the service image to build with elevated privileges. Support and actual impacts are platform-specific.
+
+```yml
+build:
+ context: .
+ privileged: true
+```
+
+### labels
+
+`labels` add metadata to the resulting image. `labels` can be set either as an array or a map.
+
+reverse-DNS notation should be used to prevent labels from conflicting with those used by other software.
+
+```yml
+build:
+ context: .
+ labels:
+ com.example.description: "Accounting webapp"
+ com.example.department: "Finance"
+ com.example.label-with-empty-value: ""
+```
+
+```yml
+build:
+ context: .
+ labels:
+ - "com.example.description=Accounting webapp"
+ - "com.example.department=Finance"
+ - "com.example.label-with-empty-value"
+```
+
+### no_cache
+
+`no_cache` disables image builder cache and enforces a full rebuild from source for all image layers. This only
+applies to layers declared in the Dockerfile, referenced images COULD be retrieved from local image store whenever tag
+has been updated on registry (see [pull](#pull)).
+
+### pull
+
+`pull` requires the image builder to pull referenced images (`FROM` Dockerfile directive), even if those are already
+available in the local image store.
+
+### shm_size
+
+`shm_size` sets the size of the shared memory (`/dev/shm` partition on Linux) allocated for building Docker images. Specify
+as an integer value representing the number of bytes or as a string expressing a [byte value](11-extension.md#specifying-byte-values).
+
+```yml
+build:
+ context: .
+ shm_size: '2gb'
+```
+
+```yaml
+build:
+ context: .
+ shm_size: 10000000
+```
+
+### target
+
+`target` defines the stage to build as defined inside a multi-stage `Dockerfile`.
+
+```yml
+build:
+ context: .
+ target: prod
+```
+
+### secrets
+`secrets` grants access to sensitive data defined by [secrets](05-services.md#secrets) on a per-service build basis. Two
+different syntax variants are supported: the short syntax and the long syntax.
+
+Compose reports an error if the secret isn't defined in the
+[`secrets`](09-secrets.md) section of this Compose file.
+
+#### Short syntax
+
+The short syntax variant only specifies the secret name. This grants the
+container access to the secret and mounts it as read-only to `/run/secrets/`
+within the container. The source name and destination mountpoint are both set
+to the secret name.
+
+The following example uses the short syntax to grant the build of the `frontend` service
+access to the `server-certificate` secret. The value of `server-certificate` is set
+to the contents of the file `./server.cert`.
+
+```yml
+services:
+ frontend:
+ build:
+ context: .
+ secrets:
+ - server-certificate
+secrets:
+ server-certificate:
+ file: ./server.cert
+```
+
+#### Long syntax
+
+The long syntax provides more granularity in how the secret is created within
+the service's containers.
+
+- `source`: The name of the secret as it exists on the platform.
+- `target`: The name of the file to be mounted in `/run/secrets/` in the
+ service's task containers. Defaults to `source` if not specified.
+- `uid` and `gid`: The numeric UID or GID that owns the file within
+ `/run/secrets/` in the service's task containers. Default value is USER running container.
+- `mode`: The [permissions](https://wintelguy.com/permissions-calc.pl) for the file to be mounted in `/run/secrets/`
+ in the service's task containers, in octal notation.
+ Default value is world-readable permissions (mode `0444`).
+ The writable bit must be ignored if set. The executable bit may be set.
+
+The following example sets the name of the `server-certificate` secret file to `server.crt`
+within the container, sets the mode to `0440` (group-readable) and sets the user and group
+to `103`. The value of `server-certificate` secret is provided by the platform through a lookup and
+the secret lifecycle not directly managed by Compose.
+
+```yml
+services:
+ frontend:
+ build:
+ context: .
+ secrets:
+ - source: server-certificate
+ target: server.cert
+ uid: "103"
+ gid: "103"
+ mode: 0440
+secrets:
+ server-certificate:
+ external: true
+```
+
+Service builds may be granted access to multiple secrets. Long and short syntax for secrets may be used in the
+same Compose file. Defining a secret in the top-level `secrets` must not imply granting any service build access to it.
+Such grant must be explicit within service specification as [secrets](05-services.md#secrets) service element.
+
+### tags
+
+`tags` defines a list of tag mappings that must be associated to the build image. This list comes in addition to
+the `image` [property defined in the service section](05-services.md#image)
+
+```yml
+tags:
+ - "myimage:mytag"
+ - "registry/username/myrepos:my-other-tag"
+```
+
+### platforms
+
+`platforms` defines a list of target [platforms](05-services.md#platform).
+
+```yml
+build:
+ context: "."
+ platforms:
+ - "linux/amd64"
+ - "linux/arm64"
+```
+
+When the `platforms` attribute is omitted, Compose includes the service's platform
+in the list of the default build target platforms.
+
+When the `platforms` attribute is defined, Compose includes the service's
+platform, otherwise users won't be able to run images they built.
+
+Composes reports an error in the following cases:
+* when the list contains multiple platforms but the implementation is incapable of storing multi-platform images
+* when the list contains an unsupported platform
+
+```yml
+build:
+ context: "."
+ platforms:
+ - "linux/amd64"
+ - "unsupported/unsupported"
+```
+* when the list is non-empty and does not contain the service's platform
+
+```yml
+services:
+ frontend:
+ platform: "linux/amd64"
+ build:
+ context: "."
+ platforms:
+ - "linux/arm64"
+```
+
+## Implementations
+
+* [docker-compose](https://docs.docker.com/compose)
+* [buildX bake](https://docs.docker.com/buildx/working-with-buildx/)
+
diff --git a/_vendor/github.com/compose-spec/compose-spec/deploy.md b/_vendor/github.com/compose-spec/compose-spec/deploy.md
new file mode 100644
index 0000000000..7f303c1a57
--- /dev/null
+++ b/_vendor/github.com/compose-spec/compose-spec/deploy.md
@@ -0,0 +1,298 @@
+# The Compose Specification - Deployment support
+{:.no_toc}
+
+*Note:* Deployment is an optional part of the Compose Specification
+
+* ToC
+{:toc}
+
+## Introduction
+
+Compose specification is a platform-neutral way to define multi-container applications. A Compose implementation supporting
+deployment of an application model may require some additional metadata as the Compose application model is an abstract way
+to reflect actual infrastructure needs per service, or lifecycle constraints.
+
+Compose Specification Deployment allows users to declare additional metadata on services so Composes gets
+relevant data to allocate adequate resources on the platform and configure them to match user's needs.
+
+## Definitions
+
+The Compose specification is extended to support an optional `deploy` subsection on services. This section defines runtime requirements
+for a service.
+
+### endpoint_mode
+
+`endpoint_mode` specifies a service discovery method for external clients connecting to a service. Default and available values
+are platform specific but the Compose specification defines two canonical values:
+
+* `endpoint_mode: vip`: Assigns the service a virtual IP (VIP) that acts as the front end for clients to reach the service
+ on a network. Platform routes requests between the client and nodes running the service, without client knowledge of how
+ many nodes are participating in the service or their IP addresses or ports.
+
+* `endpoint_mode: dnsrr`: Platform sets up DNS entries for the service such that a DNS query for the service name returns a
+ list of IP addresses (DNS round-robin), and the client connects directly to one of these.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ ports:
+ - "8080:80"
+ deploy:
+ mode: replicated
+ replicas: 2
+ endpoint_mode: vip
+```
+
+### labels
+
+`labels` specifies metadata for the service. These labels must only be set on the service and not on any containers for the service.
+This assumes the platform has some native concept of "service" that can match the Compose application model.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ deploy:
+ labels:
+ com.example.description: "This label will appear on the web service"
+```
+
+### mode
+
+`mode` defines the replication model used to run the service on the platform. Either `global` (exactly one container per physical node) or `replicated` (a specified number of containers). The default is `replicated`.
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ deploy:
+ mode: global
+```
+
+### placement
+
+`placement` specifies constraints and preferences for the platform to select a physical node to run service containers.
+
+#### constraints
+
+`constraints` defines a required property the platform's node must fulfill to run service container. Can be set either
+by a list or a map with string values.
+
+```yml
+deploy:
+ placement:
+ constraints:
+ - disktype=ssd
+```
+
+```yml
+deploy:
+ placement:
+ constraints:
+ disktype: ssd
+```
+
+#### preferences
+
+`preferences` defines a property the platform's node should fulfill to run service container. Can be set either
+by a list or a map with string values.
+
+```yml
+deploy:
+ placement:
+ preferences:
+ - datacenter=us-east
+```
+
+```yml
+deploy:
+ placement:
+ preferences:
+ datacenter: us-east
+```
+
+### replicas
+
+If the service is `replicated` (which is the default), `replicas` specifies the number of containers that should be
+running at any given time.
+
+```yml
+services:
+ fronted:
+ image: awesome/webapp
+ deploy:
+ mode: replicated
+ replicas: 6
+```
+
+### resources
+
+`resources` configures physical resource constraints for container to run on platform. Those constraints can be configured
+as:
+
+- `limits`: The platform must prevent container to allocate more
+- `reservations`: The platform must guarantee container can allocate at least the configured amount
+
+```yml
+services:
+ frontend:
+ image: awesome/webapp
+ deploy:
+ resources:
+ limits:
+ cpus: '0.50'
+ memory: 50M
+ pids: 1
+ reservations:
+ cpus: '0.25'
+ memory: 20M
+```
+
+#### cpus
+
+`cpus` configures a limit or reservation for how much of the available CPU resources (as number of cores) a container can use.
+
+#### memory
+
+`memory` configures a limit or reservation on the amount of memory a container can allocate, set as a string expressing a [byte value](11-extension.md#specifying-byte-values).
+
+#### pids
+
+`pids` tunes a container’s PIDs limit, set as an integer.
+
+#### devices
+
+`devices` configures reservations of the devices a container can use. It contains a list of reservations, each set as an object with the following parameters: `capabilities`, `driver`, `count`, `device_ids` and `options`.
+
+Devices are reserved using a list of capabilities, making `capabilities` the only required field. A device must satisfy all the requested capabilities for a successful reservation.
+
+##### capabilities
+
+`capabilities` are set as a list of strings, expressing both generic and driver specific capabilities.
+The following generic capabilities are recognized today:
+
+- `gpu`: Graphics accelerator
+- `tpu`: AI accelerator
+
+To avoid name clashes, driver specific capabilities must be prefixed with the driver name.
+For example, reserving an nVidia CUDA-enabled accelerator might look like this:
+
+```yml
+deploy:
+ resources:
+ reservations:
+ devices:
+ - capabilities: ["nvidia-compute"]
+```
+
+##### driver
+
+A different driver for the reserved device(s) can be requested using `driver` field. The value is specified as a string.
+
+```yml
+deploy:
+ resources:
+ reservations:
+ devices:
+ - capabilities: ["nvidia-compute"]
+ driver: nvidia
+```
+
+##### count
+
+If `count` is set to `all` or not specified, Compose reserves all devices that satisfy the requested capabilities. Otherwise, Compose reserves at least the number of devices specified. The value is specified as an integer.
+
+```yml
+deploy:
+ resources:
+ reservations:
+ devices:
+ - capabilities: ["tpu"]
+ count: 2
+```
+
+`count` and `device_ids` fields are exclusive. Compose returns an error if both are specified.
+
+##### device_ids
+
+If `device_ids` is set, Compose reserves devices with the specified IDs provided they satisfy the requested capabilities. The value is specified as a list of strings.
+
+```yml
+deploy:
+ resources:
+ reservations:
+ devices:
+ - capabilities: ["gpu"]
+ device_ids: ["GPU-f123d1c9-26bb-df9b-1c23-4a731f61d8c7"]
+```
+
+`count` and `device_ids` fields are exclusive. Compose returns an error if both are specified.
+
+##### options
+
+Driver specific options can be set with `options` as key-value pairs.
+
+```yml
+deploy:
+ resources:
+ reservations:
+ devices:
+ - capabilities: ["gpu"]
+ driver: gpuvendor
+ options:
+ virtualization: false
+```
+
+### restart_policy
+
+`restart_policy` configures if and how to restart containers when they exit. If `restart_policy` is not set, Compose considers the `restart` field set by service configuration.
+
+- `condition`: One of `none`, `on-failure` or `any` (default: `any`).
+- `delay`: How long to wait between restart attempts, specified as a [duration](11-extension.md#specifying-durations) (default: 0).
+- `max_attempts`: How many times to attempt to restart a container before giving up (default: never give up). If the restart does not
+ succeed within the configured `window`, this attempt doesn't count toward the configured `max_attempts` value.
+ For example, if `max_attempts` is set to '2', and the restart fails on the first attempt, more than two restarts must be attempted.
+- `window`: How long to wait before deciding if a restart has succeeded, specified as a [duration](#specifying-durations) (default:
+ decide immediately).
+
+```yml
+deploy:
+ restart_policy:
+ condition: on-failure
+ delay: 5s
+ max_attempts: 3
+ window: 120s
+```
+
+### rollback_config
+
+`rollback_config` configures how the service should be rollbacked in case of a failing update.
+
+- `parallelism`: The number of containers to rollback at a time. If set to 0, all containers rollback simultaneously.
+- `delay`: The time to wait between each container group's rollback (default 0s).
+- `failure_action`: What to do if a rollback fails. One of `continue` or `pause` (default `pause`)
+- `monitor`: Duration after each task update to monitor for failure `(ns|us|ms|s|m|h)` (default 0s).
+- `max_failure_ratio`: Failure rate to tolerate during a rollback (default 0).
+- `order`: Order of operations during rollbacks. One of `stop-first` (old task is stopped before starting new one),
+ or `start-first` (new task is started first, and the running tasks briefly overlap) (default `stop-first`).
+
+### update_config
+
+`update_config` configures how the service should be updated. Useful for configuring rolling updates.
+
+- `parallelism`: The number of containers to update at a time.
+- `delay`: The time to wait between updating a group of containers.
+- `failure_action`: What to do if an update fails. One of `continue`, `rollback`, or `pause` (default: `pause`).
+- `monitor`: Duration after each task update to monitor for failure `(ns|us|ms|s|m|h)` (default 0s).
+- `max_failure_ratio`: Failure rate to tolerate during an update.
+- `order`: Order of operations during updates. One of `stop-first` (old task is stopped before starting new one),
+ or `start-first` (new task is started first, and the running tasks briefly overlap) (default `stop-first`).
+
+```yml
+deploy:
+ update_config:
+ parallelism: 2
+ delay: 10s
+ order: stop-first
+```
diff --git a/_vendor/github.com/distribution/distribution/docs/README.md b/_vendor/github.com/distribution/distribution/docs/README.md
new file mode 100644
index 0000000000..b26dc37545
--- /dev/null
+++ b/_vendor/github.com/distribution/distribution/docs/README.md
@@ -0,0 +1,16 @@
+# The docs have been moved!
+
+The documentation for Registry has been merged into
+[the general documentation repo](https://github.com/docker/docker.github.io).
+Commit history has been preserved.
+
+The docs for Registry are now here:
+https://github.com/docker/docker.github.io/tree/master/registry
+
+> Note: The definitive [./spec directory](spec/) directory and
+[configuration.md](configuration.md) file will be maintained in this repository
+and be refreshed periodically in
+[the general documentation repo](https://github.com/docker/docker.github.io).
+
+As always, the docs in the general repo remain open-source and we appreciate
+your feedback and pull requests!
diff --git a/_vendor/github.com/distribution/distribution/docs/architecture.md b/_vendor/github.com/distribution/distribution/docs/architecture.md
new file mode 100644
index 0000000000..c2aaa9f2d7
--- /dev/null
+++ b/_vendor/github.com/distribution/distribution/docs/architecture.md
@@ -0,0 +1,52 @@
+---
+published: false
+---
+
+# Architecture
+
+## Design
+**TODO(stevvooe):** Discuss the architecture of the registry, internally and externally, in a few different deployment scenarios.
+
+### Eventual Consistency
+
+> **NOTE:** This section belongs somewhere, perhaps in a design document. We
+> are leaving this here so the information is not lost.
+
+Running the registry on eventually consistent backends has been part of the
+design from the beginning. This section covers some of the approaches to
+dealing with this reality.
+
+There are a few classes of issues that we need to worry about when
+implementing something on top of the storage drivers:
+
+1. Read-After-Write consistency (see this [article on
+ s3](http://shlomoswidler.com/2009/12/read-after-write-consistency-in-amazon.html)).
+2. [Write-Write Conflicts](http://en.wikipedia.org/wiki/Write%E2%80%93write_conflict).
+
+In reality, the registry must worry about these kinds of errors when doing the
+following:
+
+1. Accepting data into a temporary upload file may not have latest data block
+ yet (read-after-write).
+2. Moving uploaded data into its blob location (write-write race).
+3. Modifying the "current" manifest for given tag (write-write race).
+4. A whole slew of operations around deletes (read-after-write, delete-write
+ races, garbage collection, etc.).
+
+The backend path layout employs a few techniques to avoid these problems:
+
+1. Large writes are done to private upload directories. This alleviates most
+ of the corruption potential under multiple writers by avoiding multiple
+ writers.
+2. Constraints in storage driver implementations, such as support for writing
+ after the end of a file to extend it.
+3. Digest verification to avoid data corruption.
+4. Manifest files are stored by digest and cannot change.
+5. All other non-content files (links, hashes, etc.) are written as an atomic
+ unit. Anything that requires additions and deletions is broken out into
+ separate "files". Last writer still wins.
+
+Unfortunately, one must play this game when trying to build something like
+this on top of eventually consistent storage systems. If we run into serious
+problems, we can wrap the storagedrivers in a shared consistency layer but
+that would increase complexity and hinder registry cluster performance.
diff --git a/_vendor/github.com/distribution/distribution/docs/configuration.md b/_vendor/github.com/distribution/distribution/docs/configuration.md
new file mode 100644
index 0000000000..75f52deaa1
--- /dev/null
+++ b/_vendor/github.com/distribution/distribution/docs/configuration.md
@@ -0,0 +1,1269 @@
+---
+title: "Configuring a registry"
+description: "Explains how to configure a registry"
+keywords: registry, on-prem, images, tags, repository, distribution, configuration
+---
+
+The Registry configuration is based on a YAML file, detailed below. While it
+comes with sane default values out of the box, you should review it exhaustively
+before moving your systems to production.
+
+## Override specific configuration options
+
+In a typical setup where you run your Registry from the official image, you can
+specify a configuration variable from the environment by passing `-e` arguments
+to your `docker run` stanza or from within a Dockerfile using the `ENV`
+instruction.
+
+To override a configuration option, create an environment variable named
+`REGISTRY_variable` where `variable` is the name of the configuration option
+and the `_` (underscore) represents indention levels. For example, you can
+configure the `rootdirectory` of the `filesystem` storage backend:
+
+```none
+storage:
+ filesystem:
+ rootdirectory: /var/lib/registry
+```
+
+To override this value, set an environment variable like this:
+
+```none
+REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/somewhere
+```
+
+This variable overrides the `/var/lib/registry` value to the `/somewhere`
+directory.
+
+> **Note**: Create a base configuration file with environment variables that can
+> be configured to tweak individual values. Overriding configuration sections
+> with environment variables is not recommended.
+
+## Overriding the entire configuration file
+
+If the default configuration is not a sound basis for your usage, or if you are
+having issues overriding keys from the environment, you can specify an alternate
+YAML configuration file by mounting it as a volume in the container.
+
+Typically, create a new configuration file from scratch,named `config.yml`, then
+specify it in the `docker run` command:
+
+```bash
+$ docker run -d -p 5000:5000 --restart=always --name registry \
+ -v `pwd`/config.yml:/etc/docker/registry/config.yml \
+ registry:2
+```
+
+Use this
+[example YAML file](https://github.com/docker/distribution/blob/master/cmd/registry/config-example.yml)
+as a starting point.
+
+## List of configuration options
+
+These are all configuration options for the registry. Some options in the list
+are mutually exclusive. Read the detailed reference information about each
+option before finalizing your configuration.
+
+```none
+version: 0.1
+log:
+ accesslog:
+ disabled: true
+ level: debug
+ formatter: text
+ fields:
+ service: registry
+ environment: staging
+ hooks:
+ - type: mail
+ disabled: true
+ levels:
+ - panic
+ options:
+ smtp:
+ addr: mail.example.com:25
+ username: mailuser
+ password: password
+ insecure: true
+ from: sender@example.com
+ to:
+ - errors@example.com
+loglevel: debug # deprecated: use "log"
+storage:
+ filesystem:
+ rootdirectory: /var/lib/registry
+ maxthreads: 100
+ azure:
+ accountname: accountname
+ accountkey: base64encodedaccountkey
+ container: containername
+ gcs:
+ bucket: bucketname
+ keyfile: /path/to/keyfile
+ credentials:
+ type: service_account
+ project_id: project_id_string
+ private_key_id: private_key_id_string
+ private_key: private_key_string
+ client_email: client@example.com
+ client_id: client_id_string
+ auth_uri: http://example.com/auth_uri
+ token_uri: http://example.com/token_uri
+ auth_provider_x509_cert_url: http://example.com/provider_cert_url
+ client_x509_cert_url: http://example.com/client_cert_url
+ rootdirectory: /gcs/object/name/prefix
+ chunksize: 5242880
+ s3:
+ accesskey: awsaccesskey
+ secretkey: awssecretkey
+ region: us-west-1
+ regionendpoint: http://myobjects.local
+ bucket: bucketname
+ encrypt: true
+ keyid: mykeyid
+ secure: true
+ v4auth: true
+ chunksize: 5242880
+ multipartcopychunksize: 33554432
+ multipartcopymaxconcurrency: 100
+ multipartcopythresholdsize: 33554432
+ rootdirectory: /s3/object/name/prefix
+ swift:
+ username: username
+ password: password
+ authurl: https://storage.myprovider.com/auth/v1.0 or https://storage.myprovider.com/v2.0 or https://storage.myprovider.com/v3/auth
+ tenant: tenantname
+ tenantid: tenantid
+ domain: domain name for Openstack Identity v3 API
+ domainid: domain id for Openstack Identity v3 API
+ insecureskipverify: true
+ region: fr
+ container: containername
+ rootdirectory: /swift/object/name/prefix
+ oss:
+ accesskeyid: accesskeyid
+ accesskeysecret: accesskeysecret
+ region: OSS region name
+ endpoint: optional endpoints
+ internal: optional internal endpoint
+ bucket: OSS bucket
+ encrypt: optional data encryption setting
+ secure: optional ssl setting
+ chunksize: optional size valye
+ rootdirectory: optional root directory
+ inmemory: # This driver takes no parameters
+ delete:
+ enabled: false
+ redirect:
+ disable: false
+ cache:
+ blobdescriptor: redis
+ maintenance:
+ uploadpurging:
+ enabled: true
+ age: 168h
+ interval: 24h
+ dryrun: false
+ readonly:
+ enabled: false
+auth:
+ silly:
+ realm: silly-realm
+ service: silly-service
+ token:
+ autoredirect: true
+ realm: token-realm
+ service: token-service
+ issuer: registry-token-issuer
+ rootcertbundle: /root/certs/bundle
+ htpasswd:
+ realm: basic-realm
+ path: /path/to/htpasswd
+middleware:
+ registry:
+ - name: ARegistryMiddleware
+ options:
+ foo: bar
+ repository:
+ - name: ARepositoryMiddleware
+ options:
+ foo: bar
+ storage:
+ - name: cloudfront
+ options:
+ baseurl: https://my.cloudfronted.domain.com/
+ privatekey: /path/to/pem
+ keypairid: cloudfrontkeypairid
+ duration: 3000s
+ ipfilteredby: awsregion
+ awsregion: us-east-1, use-east-2
+ updatefrenquency: 12h
+ iprangesurl: https://ip-ranges.amazonaws.com/ip-ranges.json
+ storage:
+ - name: redirect
+ options:
+ baseurl: https://example.com/
+reporting:
+ bugsnag:
+ apikey: bugsnagapikey
+ releasestage: bugsnagreleasestage
+ endpoint: bugsnagendpoint
+ newrelic:
+ licensekey: newreliclicensekey
+ name: newrelicname
+ verbose: true
+http:
+ addr: localhost:5000
+ prefix: /my/nested/registry/
+ host: https://myregistryaddress.org:5000
+ secret: asecretforlocaldevelopment
+ relativeurls: false
+ draintimeout: 60s
+ tls:
+ certificate: /path/to/x509/public
+ key: /path/to/x509/private
+ clientcas:
+ - /path/to/ca.pem
+ - /path/to/another/ca.pem
+ letsencrypt:
+ cachefile: /path/to/cache-file
+ email: emailused@letsencrypt.com
+ hosts: [myregistryaddress.org]
+ debug:
+ addr: localhost:5001
+ prometheus:
+ enabled: true
+ path: /metrics
+ headers:
+ X-Content-Type-Options: [nosniff]
+ http2:
+ disabled: false
+notifications:
+ events:
+ includereferences: true
+ endpoints:
+ - name: alistener
+ disabled: false
+ url: https://my.listener.com/event
+ headers:
+ timeout: 1s
+ threshold: 10
+ backoff: 1s
+ ignoredmediatypes:
+ - application/octet-stream
+ ignore:
+ mediatypes:
+ - application/octet-stream
+ actions:
+ - pull
+redis:
+ addr: localhost:6379
+ password: asecret
+ db: 0
+ dialtimeout: 10ms
+ readtimeout: 10ms
+ writetimeout: 10ms
+ pool:
+ maxidle: 16
+ maxactive: 64
+ idletimeout: 300s
+health:
+ storagedriver:
+ enabled: true
+ interval: 10s
+ threshold: 3
+ file:
+ - file: /path/to/checked/file
+ interval: 10s
+ http:
+ - uri: http://server.to.check/must/return/200
+ headers:
+ Authorization: [Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==]
+ statuscode: 200
+ timeout: 3s
+ interval: 10s
+ threshold: 3
+ tcp:
+ - addr: redis-server.domain.com:6379
+ timeout: 3s
+ interval: 10s
+ threshold: 3
+proxy:
+ remoteurl: https://registry-1.docker.io
+ username: [username]
+ password: [password]
+compatibility:
+ schema1:
+ signingkeyfile: /etc/registry/key.json
+ enabled: true
+validation:
+ manifests:
+ urls:
+ allow:
+ - ^https?://([^/]+\.)*example\.com/
+ deny:
+ - ^https?://www\.example\.com/
+```
+
+In some instances a configuration option is **optional** but it contains child
+options marked as **required**. In these cases, you can omit the parent with
+all its children. However, if the parent is included, you must also include all
+the children marked **required**.
+
+## `version`
+
+```none
+version: 0.1
+```
+
+The `version` option is **required**. It specifies the configuration's version.
+It is expected to remain a top-level field, to allow for a consistent version
+check before parsing the remainder of the configuration file.
+
+## `log`
+
+The `log` subsection configures the behavior of the logging system. The logging
+system outputs everything to stdout. You can adjust the granularity and format
+with this configuration section.
+
+```none
+log:
+ accesslog:
+ disabled: true
+ level: debug
+ formatter: text
+ fields:
+ service: registry
+ environment: staging
+```
+
+| Parameter | Required | Description |
+|-------------|----------|-------------|
+| `level` | no | Sets the sensitivity of logging output. Permitted values are `error`, `warn`, `info`, and `debug`. The default is `info`. |
+| `formatter` | no | This selects the format of logging output. The format primarily affects how keyed attributes for a log line are encoded. Options are `text`, `json`, and `logstash`. The default is `text`. |
+| `fields` | no | A map of field names to values. These are added to every log line for the context. This is useful for identifying log messages source after being mixed in other systems. |
+
+### `accesslog`
+
+```none
+accesslog:
+ disabled: true
+```
+
+Within `log`, `accesslog` configures the behavior of the access logging
+system. By default, the access logging system outputs to stdout in
+[Combined Log Format](https://httpd.apache.org/docs/2.4/logs.html#combined).
+Access logging can be disabled by setting the boolean flag `disabled` to `true`.
+
+## `hooks`
+
+```none
+hooks:
+ - type: mail
+ levels:
+ - panic
+ options:
+ smtp:
+ addr: smtp.sendhost.com:25
+ username: sendername
+ password: password
+ insecure: true
+ from: name@sendhost.com
+ to:
+ - name@receivehost.com
+```
+
+The `hooks` subsection configures the logging hooks' behavior. This subsection
+includes a sequence handler which you can use for sending mail, for example.
+Refer to `loglevel` to configure the level of messages printed.
+
+## `loglevel`
+
+> **DEPRECATED:** Please use [log](#log) instead.
+
+```none
+loglevel: debug
+```
+
+Permitted values are `error`, `warn`, `info` and `debug`. The default is
+`info`.
+
+## `storage`
+
+```none
+storage:
+ filesystem:
+ rootdirectory: /var/lib/registry
+ azure:
+ accountname: accountname
+ accountkey: base64encodedaccountkey
+ container: containername
+ gcs:
+ bucket: bucketname
+ keyfile: /path/to/keyfile
+ credentials:
+ type: service_account
+ project_id: project_id_string
+ private_key_id: private_key_id_string
+ private_key: private_key_string
+ client_email: client@example.com
+ client_id: client_id_string
+ auth_uri: http://example.com/auth_uri
+ token_uri: http://example.com/token_uri
+ auth_provider_x509_cert_url: http://example.com/provider_cert_url
+ client_x509_cert_url: http://example.com/client_cert_url
+ rootdirectory: /gcs/object/name/prefix
+ s3:
+ accesskey: awsaccesskey
+ secretkey: awssecretkey
+ region: us-west-1
+ regionendpoint: http://myobjects.local
+ bucket: bucketname
+ encrypt: true
+ keyid: mykeyid
+ secure: true
+ v4auth: true
+ chunksize: 5242880
+ multipartcopychunksize: 33554432
+ multipartcopymaxconcurrency: 100
+ multipartcopythresholdsize: 33554432
+ rootdirectory: /s3/object/name/prefix
+ swift:
+ username: username
+ password: password
+ authurl: https://storage.myprovider.com/auth/v1.0 or https://storage.myprovider.com/v2.0 or https://storage.myprovider.com/v3/auth
+ tenant: tenantname
+ tenantid: tenantid
+ domain: domain name for Openstack Identity v3 API
+ domainid: domain id for Openstack Identity v3 API
+ insecureskipverify: true
+ region: fr
+ container: containername
+ rootdirectory: /swift/object/name/prefix
+ oss:
+ accesskeyid: accesskeyid
+ accesskeysecret: accesskeysecret
+ region: OSS region name
+ endpoint: optional endpoints
+ internal: optional internal endpoint
+ bucket: OSS bucket
+ encrypt: optional data encryption setting
+ secure: optional ssl setting
+ chunksize: optional size valye
+ rootdirectory: optional root directory
+ inmemory:
+ delete:
+ enabled: false
+ cache:
+ blobdescriptor: inmemory
+ maintenance:
+ uploadpurging:
+ enabled: true
+ age: 168h
+ interval: 24h
+ dryrun: false
+ readonly:
+ enabled: false
+ redirect:
+ disable: false
+```
+
+The `storage` option is **required** and defines which storage backend is in
+use. You must configure exactly one backend. If you configure more, the registry
+returns an error. You can choose any of these backend storage drivers:
+
+| Storage driver | Description |
+|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `filesystem` | Uses the local disk to store registry files. It is ideal for development and may be appropriate for some small-scale production applications. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/filesystem.md). |
+| `azure` | Uses Microsoft Azure Blob Storage. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/azure.md). |
+| `gcs` | Uses Google Cloud Storage. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/gcs.md). |
+| `s3` | Uses Amazon Simple Storage Service (S3) and compatible Storage Services. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/s3.md). |
+| `swift` | Uses Openstack Swift object storage. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/swift.md). |
+| `oss` | Uses Aliyun OSS for object storage. See the [driver's reference documentation](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/oss.md). |
+
+For testing only, you can use the [`inmemory` storage
+driver](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/inmemory.md).
+If you would like to run a registry from volatile memory, use the
+[`filesystem` driver](https://github.com/docker/docker.github.io/tree/master/registry/storage-drivers/filesystem.md)
+on a ramdisk.
+
+If you are deploying a registry on Windows, a Windows volume mounted from the
+host is not recommended. Instead, you can use a S3 or Azure backing
+data-store. If you do use a Windows volume, the length of the `PATH` to
+the mount point must be within the `MAX_PATH` limits (typically 255 characters),
+or this error will occur:
+
+```none
+mkdir /XXX protocol error and your registry will not function properly.
+```
+
+### `maintenance`
+
+Currently, upload purging and read-only mode are the only `maintenance`
+functions available.
+
+### `uploadpurging`
+
+Upload purging is a background process that periodically removes orphaned files
+from the upload directories of the registry. Upload purging is enabled by
+default. To configure upload directory purging, the following parameters must
+be set.
+
+
+| Parameter | Required | Description |
+|------------|----------|----------------------------------------------------------------------------------------------------|
+| `enabled` | yes | Set to `true` to enable upload purging. Defaults to `true`. |
+| `age` | yes | Upload directories which are older than this age will be deleted.Defaults to `168h` (1 week). |
+| `interval` | yes | The interval between upload directory purging. Defaults to `24h`. |
+| `dryrun` | yes | Set `dryrun` to `true` to obtain a summary of what directories will be deleted. Defaults to `false`.|
+
+> **Note**: `age` and `interval` are strings containing a number with optional
+fraction and a unit suffix. Some examples: `45m`, `2h10m`, `168h`.
+
+### `readonly`
+
+If the `readonly` section under `maintenance` has `enabled` set to `true`,
+clients will not be allowed to write to the registry. This mode is useful to
+temporarily prevent writes to the backend storage so a garbage collection pass
+can be run. Before running garbage collection, the registry should be
+restarted with readonly's `enabled` set to true. After the garbage collection
+pass finishes, the registry may be restarted again, this time with `readonly`
+removed from the configuration (or set to false).
+
+### `delete`
+
+Use the `delete` structure to enable the deletion of image blobs and manifests
+by digest. It defaults to false, but it can be enabled by writing the following
+on the configuration file:
+
+```none
+delete:
+ enabled: true
+```
+
+### `cache`
+
+Use the `cache` structure to enable caching of data accessed in the storage
+backend. Currently, the only available cache provides fast access to layer
+metadata, which uses the `blobdescriptor` field if configured.
+
+You can set `blobdescriptor` field to `redis` or `inmemory`. If set to `redis`,a
+Redis pool caches layer metadata. If set to `inmemory`, an in-memory map caches
+layer metadata.
+
+> **NOTE**: Formerly, `blobdescriptor` was known as `layerinfo`. While these
+> are equivalent, `layerinfo` has been deprecated.
+
+### `redirect`
+
+The `redirect` subsection provides configuration for managing redirects from
+content backends. For backends that support it, redirecting is enabled by
+default. In certain deployment scenarios, you may decide to route all data
+through the Registry, rather than redirecting to the backend. This may be more
+efficient when using a backend that is not co-located or when a registry
+instance is aggressively caching.
+
+To disable redirects, add a single flag `disable`, set to `true`
+under the `redirect` section:
+
+```none
+redirect:
+ disable: true
+```
+
+## `auth`
+
+```none
+auth:
+ silly:
+ realm: silly-realm
+ service: silly-service
+ token:
+ realm: token-realm
+ service: token-service
+ issuer: registry-token-issuer
+ rootcertbundle: /root/certs/bundle
+ htpasswd:
+ realm: basic-realm
+ path: /path/to/htpasswd
+```
+
+The `auth` option is **optional**. Possible auth providers include:
+
+- [`silly`](#silly)
+- [`token`](#token)
+- [`htpasswd`](#htpasswd)
+- [`none`]
+
+You can configure only one authentication provider.
+
+### `silly`
+
+The `silly` authentication provider is only appropriate for development. It simply checks
+for the existence of the `Authorization` header in the HTTP request. It does not
+check the header's value. If the header does not exist, the `silly` auth
+responds with a challenge response, echoing back the realm, service, and scope
+for which access was denied.
+
+The following values are used to configure the response:
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `realm` | yes | The realm in which the registry server authenticates. |
+| `service` | yes | The service being authenticated. |
+
+### `token`
+
+Token-based authentication allows you to decouple the authentication system from
+the registry. It is an established authentication paradigm with a high degree of
+security.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `realm` | yes | The realm in which the registry server authenticates. |
+| `service` | yes | The service being authenticated. |
+| `issuer` | yes | The name of the token issuer. The issuer inserts this into the token so it must match the value configured for the issuer. |
+| `rootcertbundle` | yes | The absolute path to the root certificate bundle. This bundle contains the public part of the certificates used to sign authentication tokens. |
+| `autoredirect` | no | When set to `true`, `realm` will automatically be set using the Host header of the request as the domain and a path of `/auth/token/`|
+
+
+For more information about Token based authentication configuration, see the
+[specification](spec/auth/token.md).
+
+### `htpasswd`
+
+The _htpasswd_ authentication backed allows you to configure basic
+authentication using an
+[Apache htpasswd file](https://httpd.apache.org/docs/2.4/programs/htpasswd.html).
+The only supported password format is
+[`bcrypt`](http://en.wikipedia.org/wiki/Bcrypt). Entries with other hash types
+are ignored. The `htpasswd` file is loaded once, at startup. If the file is
+invalid, the registry will display an error and will not start.
+
+> **Warning**: If the `htpasswd` file is missing, the file will be created and provisioned with a default user and automatically generated password.
+> The password will be printed to stdout.
+
+> **Warning**: Only use the `htpasswd` authentication scheme with TLS
+> configured, since basic authentication sends passwords as part of the HTTP
+> header.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `realm` | yes | The realm in which the registry server authenticates. |
+| `path` | yes | The path to the `htpasswd` file to load at startup. |
+
+## `middleware`
+
+The `middleware` structure is **optional**. Use this option to inject middleware at
+named hook points. Each middleware must implement the same interface as the
+object it is wrapping. For instance, a registry middleware must implement the
+`distribution.Namespace` interface, while a repository middleware must implement
+`distribution.Repository`, and a storage middleware must implement
+`driver.StorageDriver`.
+
+This is an example configuration of the `cloudfront` middleware, a storage
+middleware:
+
+```none
+middleware:
+ registry:
+ - name: ARegistryMiddleware
+ options:
+ foo: bar
+ repository:
+ - name: ARepositoryMiddleware
+ options:
+ foo: bar
+ storage:
+ - name: cloudfront
+ options:
+ baseurl: https://my.cloudfronted.domain.com/
+ privatekey: /path/to/pem
+ keypairid: cloudfrontkeypairid
+ duration: 3000s
+ ipfilteredby: awsregion
+ awsregion: us-east-1, use-east-2
+ updatefrenquency: 12h
+ iprangesurl: https://ip-ranges.amazonaws.com/ip-ranges.json
+```
+
+Each middleware entry has `name` and `options` entries. The `name` must
+correspond to the name under which the middleware registers itself. The
+`options` field is a map that details custom configuration required to
+initialize the middleware. It is treated as a `map[string]interface{}`. As such,
+it supports any interesting structures desired, leaving it up to the middleware
+initialization function to best determine how to handle the specific
+interpretation of the options.
+
+### `cloudfront`
+
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `baseurl` | yes | The `SCHEME://HOST[/PATH]` at which Cloudfront is served. |
+| `privatekey` | yes | The private key for Cloudfront, provided by AWS. |
+| `keypairid` | yes | The key pair ID provided by AWS. |
+| `duration` | no | An integer and unit for the duration of the Cloudfront session. Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, or `h`. For example, `3000s` is valid, but `3000 s` is not. If you do not specify a `duration` or you specify an integer without a time unit, the duration defaults to `20m` (20 minutes). |
+| `ipfilteredby` | no | A string with the following value `none`, `aws` or `awsregion`. |
+| `awsregion` | no | A comma separated string of AWS regions, only available when `ipfilteredby` is `awsregion`. For example, `us-east-1, us-west-2` |
+| `updatefrenquency` | no | The frequency to update AWS IP regions, default: `12h` |
+| `iprangesurl` | no | The URL contains the AWS IP ranges information, default: `https://ip-ranges.amazonaws.com/ip-ranges.json` |
+
+
+Value of `ipfilteredby` can be:
+
+| Value | Description |
+|-------------|------------------------------------|
+| `none` | default, do not filter by IP |
+| `aws` | IP from AWS goes to S3 directly |
+| `awsregion` | IP from certain AWS regions goes to S3 directly, use together with `awsregion`. |
+
+### `redirect`
+
+You can use the `redirect` storage middleware to specify a custom URL to a
+location of a proxy for the layer stored by the S3 storage driver.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------------------------------------------------------------|
+| `baseurl` | yes | `SCHEME://HOST` at which layers are served. Can also contain port. For example, `https://example.com:5443`. |
+
+## `reporting`
+
+```
+reporting:
+ bugsnag:
+ apikey: bugsnagapikey
+ releasestage: bugsnagreleasestage
+ endpoint: bugsnagendpoint
+ newrelic:
+ licensekey: newreliclicensekey
+ name: newrelicname
+ verbose: true
+```
+
+The `reporting` option is **optional** and configures error and metrics
+reporting tools. At the moment only two services are supported:
+
+- [Bugsnag](#bugsnag)
+- [New Relic](#new-relic)
+
+A valid configuration may contain both.
+
+### `bugsnag`
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `apikey` | yes | The API Key provided by Bugsnag. |
+| `releasestage` | no | Tracks where the registry is deployed, using a string like `production`, `staging`, or `development`.|
+| `endpoint`| no | The enterprise Bugsnag endpoint. |
+
+### `newrelic`
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `licensekey` | yes | License key provided by New Relic. |
+| `name` | no | New Relic application name. |
+| `verbose`| no | Set to `true` to enable New Relic debugging output on `stdout`. |
+
+## `http`
+
+```none
+http:
+ addr: localhost:5000
+ net: tcp
+ prefix: /my/nested/registry/
+ host: https://myregistryaddress.org:5000
+ secret: asecretforlocaldevelopment
+ relativeurls: false
+ draintimeout: 60s
+ tls:
+ certificate: /path/to/x509/public
+ key: /path/to/x509/private
+ clientcas:
+ - /path/to/ca.pem
+ - /path/to/another/ca.pem
+ minimumtls: tls1.2
+ ciphersuites:
+ - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+ - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+ letsencrypt:
+ cachefile: /path/to/cache-file
+ email: emailused@letsencrypt.com
+ hosts: [myregistryaddress.org]
+ debug:
+ addr: localhost:5001
+ headers:
+ X-Content-Type-Options: [nosniff]
+ http2:
+ disabled: false
+```
+
+The `http` option details the configuration for the HTTP server that hosts the
+registry.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `addr` | yes | The address for which the server should accept connections. The form depends on a network type (see the `net` option). Use `HOST:PORT` for TCP and `FILE` for a UNIX socket. |
+| `net` | no | The network used to create a listening socket. Known networks are `unix` and `tcp`. |
+| `prefix` | no | If the server does not run at the root path, set this to the value of the prefix. The root path is the section before `v2`. It requires both preceding and trailing slashes, such as in the example `/path/`. |
+| `host` | no | A fully-qualified URL for an externally-reachable address for the registry. If present, it is used when creating generated URLs. Otherwise, these URLs are derived from client requests. |
+| `secret` | no | A random piece of data used to sign state that may be stored with the client to protect against tampering. For production environments you should generate a random piece of data using a cryptographically secure random generator. If you omit the secret, the registry will automatically generate a secret when it starts. **If you are building a cluster of registries behind a load balancer, you MUST ensure the secret is the same for all registries.**|
+| `relativeurls`| no | If `true`, the registry returns relative URLs in Location headers. The client is responsible for resolving the correct URL. **This option is not compatible with Docker 1.7 and earlier.**|
+| `draintimeout`| no | Amount of time to wait for HTTP connections to drain before shutting down after registry receives SIGTERM signal|
+
+
+### `tls`
+
+The `tls` structure within `http` is **optional**. Use this to configure TLS
+for the server. If you already have a web server running on
+the same host as the registry, you may prefer to configure TLS on that web server
+and proxy connections to the registry server.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `certificate` | yes | Absolute path to the x509 certificate file. |
+| `key` | yes | Absolute path to the x509 private key file. |
+| `clientcas` | no | An array of absolute paths to x509 CA files. |
+| `minimumtls` | no | Minimum TLS version allowed (tls1.0, tls1.1, tls1.2, tls1.3). Defaults to tls1.2 |
+| `ciphersuites` | no | Cipher suites allowed. Please see below for allowed values and default. |
+
+Available cipher suites:
+- TLS_RSA_WITH_RC4_128_SHA
+- TLS_RSA_WITH_3DES_EDE_CBC_SHA
+- TLS_RSA_WITH_AES_128_CBC_SHA
+- TLS_RSA_WITH_AES_256_CBC_SHA
+- TLS_RSA_WITH_AES_128_CBC_SHA256
+- TLS_RSA_WITH_AES_128_GCM_SHA256
+- TLS_RSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
+- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
+- TLS_ECDHE_RSA_WITH_RC4_128_SHA
+- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
+- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
+- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
+- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
+- TLS_AES_128_GCM_SHA256
+- TLS_AES_256_GCM_SHA384
+- TLS_CHACHA20_POLY1305_SHA256
+
+Default cipher suites:
+- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
+- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
+- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+- TLS_AES_128_GCM_SHA256
+- TLS_CHACHA20_POLY1305_SHA256
+- TLS_AES_256_GCM_SHA384
+
+### `letsencrypt`
+
+The `letsencrypt` structure within `tls` is **optional**. Use this to configure
+TLS certificates provided by
+[Let's Encrypt](https://letsencrypt.org/how-it-works/).
+
+>**NOTE**: When using Let's Encrypt, ensure that the outward-facing address is
+> accessible on port `443`. The registry defaults to listening on port `5000`.
+> If you run the registry as a container, consider adding the flag `-p 443:5000`
+> to the `docker run` command or using a similar setting in a cloud
+> configuration. You should also set the `hosts` option to the list of hostnames
+> that are valid for this registry to avoid trying to get certificates for random
+> hostnames due to malicious clients connecting with bogus SNI hostnames.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `cachefile` | yes | Absolute path to a file where the Let's Encrypt agent can cache data. |
+| `email` | yes | The email address used to register with Let's Encrypt. |
+| `hosts` | no | The hostnames allowed for Let's Encrypt certificates. |
+
+### `debug`
+
+The `debug` option is **optional** . Use it to configure a debug server that
+can be helpful in diagnosing problems. The debug endpoint can be used for
+monitoring registry metrics and health, as well as profiling. Sensitive
+information may be available via the debug endpoint. Please be certain that
+access to the debug endpoint is locked down in a production environment.
+
+The `debug` section takes a single required `addr` parameter, which specifies
+the `HOST:PORT` on which the debug server should accept connections.
+
+## `prometheus`
+
+The `prometheus` option defines whether the prometheus metrics is enable, as well
+as the path to access the metrics.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `enabled` | no | Set `true` to enable the prometheus server |
+| `path` | no | The path to access the metrics, `/metrics` by default |
+
+The url to access the metrics is `HOST:PORT/path`, where `HOST:PORT` is defined
+in `addr` under `debug`.
+
+### `headers`
+
+The `headers` option is **optional** . Use it to specify headers that the HTTP
+server should include in responses. This can be used for security headers such
+as `Strict-Transport-Security`.
+
+The `headers` option should contain an option for each header to include, where
+the parameter name is the header's name, and the parameter value a list of the
+header's payload values.
+
+Including `X-Content-Type-Options: [nosniff]` is recommended, so that browsers
+will not interpret content as HTML if they are directed to load a page from the
+registry. This header is included in the example configuration file.
+
+### `http2`
+
+The `http2` structure within `http` is **optional**. Use this to control http2
+settings for the registry.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `disabled` | no | If `true`, then `http2` support is disabled. |
+
+## `notifications`
+
+```none
+notifications:
+ events:
+ includereferences: true
+ endpoints:
+ - name: alistener
+ disabled: false
+ url: https://my.listener.com/event
+ headers:
+ timeout: 1s
+ threshold: 10
+ backoff: 1s
+ ignoredmediatypes:
+ - application/octet-stream
+ ignore:
+ mediatypes:
+ - application/octet-stream
+ actions:
+ - pull
+```
+
+The notifications option is **optional** and currently may contain a single
+option, `endpoints`.
+
+### `endpoints`
+
+The `endpoints` structure contains a list of named services (URLs) that can
+accept event notifications.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `name` | yes | A human-readable name for the service. |
+| `disabled` | no | If `true`, notifications are disabled for the service.|
+| `url` | yes | The URL to which events should be published. |
+| `headers` | yes | A list of static headers to add to each request. Each header's name is a key beneath `headers`, and each value is a list of payloads for that header name. Values must always be lists. |
+| `timeout` | yes | A value for the HTTP timeout. A positive integer and an optional suffix indicating the unit of time, which may be `ns`, `us`, `ms`, `s`, `m`, or `h`. If you omit the unit of time, `ns` is used. |
+| `threshold` | yes | An integer specifying how long to wait before backing off a failure. |
+| `backoff` | yes | How long the system backs off before retrying after a failure. A positive integer and an optional suffix indicating the unit of time, which may be `ns`, `us`, `ms`, `s`, `m`, or `h`. If you omit the unit of time, `ns` is used. |
+| `ignoredmediatypes`|no| A list of target media types to ignore. Events with these target media types are not published to the endpoint. |
+| `ignore` |no| Events with these mediatypes or actions are not published to the endpoint. |
+
+#### `ignore`
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `mediatypes`|no| A list of target media types to ignore. Events with these target media types are not published to the endpoint. |
+| `actions` |no| A list of actions to ignore. Events with these actions are not published to the endpoint. |
+
+### `events`
+
+The `events` structure configures the information provided in event notifications.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `includereferences` | no | If `true`, include reference information in manifest events. |
+
+## `redis`
+
+```none
+redis:
+ addr: localhost:6379
+ password: asecret
+ db: 0
+ dialtimeout: 10ms
+ readtimeout: 10ms
+ writetimeout: 10ms
+ pool:
+ maxidle: 16
+ maxactive: 64
+ idletimeout: 300s
+```
+
+Declare parameters for constructing the `redis` connections. Registry instances
+may use the Redis instance for several applications. Currently, it caches
+information about immutable blobs. Most of the `redis` options control
+how the registry connects to the `redis` instance. You can control the pool's
+behavior with the [pool](#pool) subsection.
+
+You should configure Redis with the **allkeys-lru** eviction policy, because the
+registry does not set an expiration value on keys.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `addr` | yes | The address (host and port) of the Redis instance. |
+| `password`| no | A password used to authenticate to the Redis instance.|
+| `db` | no | The name of the database to use for each connection. |
+| `dialtimeout` | no | The timeout for connecting to the Redis instance. |
+| `readtimeout` | no | The timeout for reading from the Redis instance. |
+| `writetimeout` | no | The timeout for writing to the Redis instance. |
+
+### `pool`
+
+```none
+pool:
+ maxidle: 16
+ maxactive: 64
+ idletimeout: 300s
+```
+
+Use these settings to configure the behavior of the Redis connection pool.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `maxidle` | no | The maximum number of idle connections in the pool. |
+| `maxactive`| no | The maximum number of connections which can be open before blocking a connection request. |
+| `idletimeout`| no | How long to wait before closing inactive connections. |
+
+## `health`
+
+```none
+health:
+ storagedriver:
+ enabled: true
+ interval: 10s
+ threshold: 3
+ file:
+ - file: /path/to/checked/file
+ interval: 10s
+ http:
+ - uri: http://server.to.check/must/return/200
+ headers:
+ Authorization: [Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==]
+ statuscode: 200
+ timeout: 3s
+ interval: 10s
+ threshold: 3
+ tcp:
+ - addr: redis-server.domain.com:6379
+ timeout: 3s
+ interval: 10s
+ threshold: 3
+```
+
+The health option is **optional**, and contains preferences for a periodic
+health check on the storage driver's backend storage, as well as optional
+periodic checks on local files, HTTP URIs, and/or TCP servers. The results of
+the health checks are available at the `/debug/health` endpoint on the debug
+HTTP server if the debug HTTP server is enabled (see http section).
+
+### `storagedriver`
+
+The `storagedriver` structure contains options for a health check on the
+configured storage driver's backend storage. The health check is only active
+when `enabled` is set to `true`.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `enabled` | yes | Set to `true` to enable storage driver health checks or `false` to disable them. |
+| `interval`| no | How long to wait between repetitions of the storage driver health check. A positive integer and an optional suffix indicating the unit of time. The suffix is one of `ns`, `us`, `ms`, `s`, `m`, or `h`. Defaults to `10s` if the value is omitted. If you specify a value but omit the suffix, the value is interpreted as a number of nanoseconds. |
+| `threshold`| no | A positive integer which represents the number of times the check must fail before the state is marked as unhealthy. If not specified, a single failure marks the state as unhealthy. |
+
+### `file`
+
+The `file` structure includes a list of paths to be periodically checked for the\
+existence of a file. If a file exists at the given path, the health check will
+fail. You can use this mechanism to bring a registry out of rotation by creating
+a file.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `file` | yes | The path to check for existence of a file. |
+| `interval`| no | How long to wait before repeating the check. A positive integer and an optional suffix indicating the unit of time. The suffix is one of `ns`, `us`, `ms`, `s`, `m`, or `h`. Defaults to `10s` if the value is omitted. If you specify a value but omit the suffix, the value is interpreted as a number of nanoseconds. |
+
+### `http`
+
+The `http` structure includes a list of HTTP URIs to periodically check with
+`HEAD` requests. If a `HEAD` request does not complete or returns an unexpected
+status code, the health check will fail.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `uri` | yes | The URI to check. |
+| `headers` | no | Static headers to add to each request. Each header's name is a key beneath `headers`, and each value is a list of payloads for that header name. Values must always be lists. |
+| `statuscode` | no | The expected status code from the HTTP URI. Defaults to `200`. |
+| `timeout` | no | How long to wait before timing out the HTTP request. A positive integer and an optional suffix indicating the unit of time. The suffix is one of `ns`, `us`, `ms`, `s`, `m`, or `h`. If you specify a value but omit the suffix, the value is interpreted as a number of nanoseconds. |
+| `interval`| no | How long to wait before repeating the check. A positive integer and an optional suffix indicating the unit of time. The suffix is one of `ns`, `us`, `ms`, `s`, `m`, or `h`. Defaults to `10s` if the value is omitted. If you specify a value but omit the suffix, the value is interpreted as a number of nanoseconds. |
+| `threshold`| no | The number of times the check must fail before the state is marked as unhealthy. If this field is not specified, a single failure marks the state as unhealthy. |
+
+### `tcp`
+
+The `tcp` structure includes a list of TCP addresses to periodically check using
+TCP connection attempts. Addresses must include port numbers. If a connection
+attempt fails, the health check will fail.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `addr` | yes | The TCP address and port to connect to. |
+| `timeout` | no | How long to wait before timing out the TCP connection. A positive integer and an optional suffix indicating the unit of time. The suffix is one of `ns`, `us`, `ms`, `s`, `m`, or `h`. If you specify a value but omit the suffix, the value is interpreted as a number of nanoseconds. |
+| `interval`| no | How long to wait between repetitions of the check. A positive integer and an optional suffix indicating the unit of time. The suffix is one of `ns`, `us`, `ms`, `s`, `m`, or `h`. Defaults to `10s` if the value is omitted. If you specify a value but omit the suffix, the value is interpreted as a number of nanoseconds. |
+| `threshold`| no | The number of times the check must fail before the state is marked as unhealthy. If this field is not specified, a single failure marks the state as unhealthy. |
+
+
+## `proxy`
+
+```
+proxy:
+ remoteurl: https://registry-1.docker.io
+ username: [username]
+ password: [password]
+```
+
+The `proxy` structure allows a registry to be configured as a pull-through cache
+to Docker Hub. See
+[mirror](https://github.com/docker/docker.github.io/tree/master/registry/recipes/mirror.md)
+for more information. Pushing to a registry configured as a pull-through cache
+is unsupported.
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `remoteurl`| yes | The URL for the repository on Docker Hub. |
+| `username` | no | The username registered with Docker Hub which has access to the repository. |
+| `password` | no | The password used to authenticate to Docker Hub using the username specified in `username`. |
+
+
+To enable pulling private repositories (e.g. `batman/robin`) specify the
+username (such as `batman`) and the password for that username.
+
+> **Note**: These private repositories are stored in the proxy cache's storage.
+> Take appropriate measures to protect access to the proxy cache.
+
+## `compatibility`
+
+```none
+compatibility:
+ schema1:
+ signingkeyfile: /etc/registry/key.json
+ enabled: true
+```
+
+Use the `compatibility` structure to configure handling of older and deprecated
+features. Each subsection defines such a feature with configurable behavior.
+
+### `schema1`
+
+| Parameter | Required | Description |
+|-----------|----------|-------------------------------------------------------|
+| `signingkeyfile` | no | The signing private key used to add signatures to `schema1` manifests. If no signing key is provided, a new ECDSA key is generated when the registry starts. |
+| `enabled` | no | If this is not set to true, `schema1` manifests cannot be pushed. |
+
+## `validation`
+
+```none
+validation:
+ manifests:
+ urls:
+ allow:
+ - ^https?://([^/]+\.)*example\.com/
+ deny:
+ - ^https?://www\.example\.com/
+```
+
+### `disabled`
+
+The `disabled` flag disables the other options in the `validation`
+section. They are enabled by default. This option deprecates the `enabled` flag.
+
+### `manifests`
+
+Use the `manifests` subsection to configure validation of manifests. If
+`disabled` is `false`, the validation allows nothing.
+
+#### `urls`
+
+The `allow` and `deny` options are each a list of
+[regular expressions](https://godoc.org/regexp/syntax) that restrict the URLs in
+pushed manifests.
+
+If `allow` is unset, pushing a manifest containing URLs fails.
+
+If `allow` is set, pushing a manifest succeeds only if all URLs match
+one of the `allow` regular expressions **and** one of the following holds:
+
+1. `deny` is unset.
+2. `deny` is set but no URLs within the manifest match any of the `deny` regular
+ expressions.
+
+## Example: Development configuration
+
+You can use this simple example for local development:
+
+```none
+version: 0.1
+log:
+ level: debug
+storage:
+ filesystem:
+ rootdirectory: /var/lib/registry
+http:
+ addr: localhost:5000
+ secret: asecretforlocaldevelopment
+ debug:
+ addr: localhost:5001
+```
+
+This example configures the registry instance to run on port `5000`, binding to
+`localhost`, with the `debug` server enabled. Registry data is stored in the
+`/var/lib/registry` directory. Logging is set to `debug` mode, which is the most
+verbose.
+
+See
+[config-example.yml](https://github.com/docker/distribution/blob/master/cmd/registry/config-example.yml)
+for another simple configuration. Both examples are generally useful for local
+development.
+
+
+## Example: Middleware configuration
+
+This example configures [Amazon Cloudfront](http://aws.amazon.com/cloudfront/)
+as the storage middleware in a registry. Middleware allows the registry to serve
+layers via a content delivery network (CDN). This reduces requests to the
+storage layer.
+
+Cloudfront requires the S3 storage driver.
+
+This is the configuration expressed in YAML:
+
+```none
+middleware:
+ storage:
+ - name: cloudfront
+ disabled: false
+ options:
+ baseurl: http://d111111abcdef8.cloudfront.net
+ privatekey: /path/to/asecret.pem
+ keypairid: asecret
+ duration: 60s
+```
+
+See the configuration reference for [Cloudfront](#cloudfront) for more
+information about configuration options.
+
+> **Note**: Cloudfront keys exist separately from other AWS keys. See
+> [the documentation on AWS credentials](http://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)
+> for more information.
diff --git a/_vendor/github.com/distribution/distribution/docs/spec/api.md b/_vendor/github.com/distribution/distribution/docs/spec/api.md
new file mode 100644
index 0000000000..e088ad9461
--- /dev/null
+++ b/_vendor/github.com/distribution/distribution/docs/spec/api.md
@@ -0,0 +1,5487 @@
+---
+title: "HTTP API V2"
+description: "Specification for the Registry API."
+keywords: registry, on-prem, images, tags, repository, distribution, api, advanced
+redirect_from:
+ - /reference/api/registry_api/
+---
+
+# Docker Registry HTTP API V2
+
+## Introduction
+
+The _Docker Registry HTTP API_ is the protocol to facilitate distribution of
+images to the docker engine. It interacts with instances of the docker
+registry, which is a service to manage information about docker images and
+enable their distribution. The specification covers the operation of version 2
+of this API, known as _Docker Registry HTTP API V2_.
+
+While the V1 registry protocol is usable, there are several problems with the
+architecture that have led to this new version. The main driver of this
+specification is a set of changes to the Docker image format, covered in
+[docker/docker#8093](https://github.com/docker/docker/issues/8093).
+The new, self-contained image manifest simplifies image definition and improves
+security. This specification will build on that work, leveraging new properties
+of the manifest format to improve performance, reduce bandwidth usage and
+decrease the likelihood of backend corruption.
+
+For relevant details and history leading up to this specification, please see
+the following issues:
+
+- [docker/docker#8093](https://github.com/docker/docker/issues/8093)
+- [docker/docker#9015](https://github.com/docker/docker/issues/9015)
+- [docker/docker-registry#612](https://github.com/docker/docker-registry/issues/612)
+
+### Scope
+
+This specification covers the URL layout and protocols of the interaction
+between docker registry and docker core. This will affect the docker core
+registry API and the rewrite of docker-registry. Docker registry
+implementations may implement other API endpoints, but they are not covered by
+this specification.
+
+This includes the following features:
+
+- Namespace-oriented URI Layout
+- PUSH/PULL registry server for V2 image manifest format
+- Resumable layer PUSH support
+- V2 Client library implementation
+
+While authentication and authorization support will influence this
+specification, details of the protocol will be left to a future specification.
+Relevant header definitions and error codes are present to provide an
+indication of what a client may encounter.
+
+#### Future
+
+There are features that have been discussed during the process of cutting this
+specification. The following is an incomplete list:
+
+- Immutable image references
+- Multiple architecture support
+- Migration from v2compatibility representation
+
+These may represent features that are either out of the scope of this
+specification, the purview of another specification or have been deferred to a
+future version.
+
+### Use Cases
+
+For the most part, the use cases of the former registry API apply to the new
+version. Differentiating use cases are covered below.
+
+#### Image Verification
+
+A docker engine instance would like to run verified image named
+"library/ubuntu", with the tag "latest". The engine contacts the registry,
+requesting the manifest for "library/ubuntu:latest". An untrusted registry
+returns a manifest. Before proceeding to download the individual layers, the
+engine verifies the manifest's signature, ensuring that the content was
+produced from a trusted source and no tampering has occurred. After each layer
+is downloaded, the engine verifies the digest of the layer, ensuring that the
+content matches that specified by the manifest.
+
+#### Resumable Push
+
+Company X's build servers lose connectivity to docker registry before
+completing an image layer transfer. After connectivity returns, the build
+server attempts to re-upload the image. The registry notifies the build server
+that the upload has already been partially attempted. The build server
+responds by only sending the remaining data to complete the image file.
+
+#### Resumable Pull
+
+Company X is having more connectivity problems but this time in their
+deployment datacenter. When downloading an image, the connection is
+interrupted before completion. The client keeps the partial data and uses http
+`Range` requests to avoid downloading repeated data.
+
+#### Layer Upload De-duplication
+
+Company Y's build system creates two identical docker layers from build
+processes A and B. Build process A completes uploading the layer before B.
+When process B attempts to upload the layer, the registry indicates that its
+not necessary because the layer is already known.
+
+If process A and B upload the same layer at the same time, both operations
+will proceed and the first to complete will be stored in the registry (Note:
+we may modify this to prevent dogpile with some locking mechanism).
+
+### Changes
+
+The V2 specification has been written to work as a living document, specifying
+only what is certain and leaving what is not specified open or to future
+changes. Only non-conflicting additions should be made to the API and accepted
+changes should avoid preventing future changes from happening.
+
+This section should be updated when changes are made to the specification,
+indicating what is different. Optionally, we may start marking parts of the
+specification to correspond with the versions enumerated here.
+
+Each set of changes is given a letter corresponding to a set of modifications
+that were applied to the baseline specification. These are merely for
+reference and shouldn't be used outside the specification other than to
+identify a set of modifications.
+
+
+
l
+
+
+
Document TOOMANYREQUESTS error code.
+
+
+
+
k
+
+
+
Document use of Accept and Content-Type headers in manifests endpoint.
+
+
+
+
j
+
+
+
Add ability to mount blobs across repositories.
+
+
+
+
i
+
+
+
Clarified expected behavior response to manifest HEAD request.
+
+
+
+
h
+
+
+
All mention of tarsum removed.
+
+
+
+
g
+
+
+
Clarify behavior of pagination behavior with unspecified parameters.
+
+
+
+
f
+
+
+
Specify the delete API for layers and manifests.
+
+
+
+
e
+
+
+
Added support for listing registry contents.
+
Added pagination to tags API.
+
Added common approach to support pagination.
+
+
+
+
d
+
+
+
Allow repository name components to be one character.
+
Clarified that single component names are allowed.
+
+
+
+
c
+
+
+
Added section covering digest format.
+
Added more clarification that manifest cannot be deleted by tag.
+
+
+
+
b
+
+
+
Added capability of doing streaming upload to PATCH blob upload.
+
Updated PUT blob upload to no longer take final chunk, now requires entire data or no data.
+
Removed `416 Requested Range Not Satisfiable` response status from PUT blob upload.
+
+
+
+
a
+
+
+
Added support for immutable manifest references in manifest endpoints.
+
Deleting a manifest by tag has been deprecated.
+
Specified `Docker-Content-Digest` header for appropriate entities.
+
Added error code for unsupported operations.
+
+
+
+
+## Overview
+
+This section covers client flows and details of the API endpoints. The URI
+layout of the new API is structured to support a rich authentication and
+authorization model by leveraging namespaces. All endpoints will be prefixed
+by the API version and the repository name:
+
+ /v2//
+
+For example, an API endpoint that will work with the `library/ubuntu`
+repository, the URI prefix will be:
+
+ /v2/library/ubuntu/
+
+This scheme provides rich access control over various operations and methods
+using the URI prefix and http methods that can be controlled in variety of
+ways.
+
+Classically, repository names have always been two path components where each
+path component is less than 30 characters. The V2 registry API does not
+enforce this. The rules for a repository name are as follows:
+
+1. A repository name is broken up into _path components_. A component of a
+ repository name must be at least one lowercase, alpha-numeric characters,
+ optionally separated by periods, dashes or underscores. More strictly, it
+ must match the regular expression `[a-z0-9]+(?:[._-][a-z0-9]+)*`.
+2. If a repository name has two or more path components, they must be
+ separated by a forward slash ("/").
+3. The total length of a repository name, including slashes, must be less than
+ 256 characters.
+
+These name requirements _only_ apply to the registry API and should accept a
+superset of what is supported by other docker ecosystem components.
+
+All endpoints should support aggressive http caching, compression and range
+headers, where appropriate. The new API attempts to leverage HTTP semantics
+where possible but may break from standards to implement targeted features.
+
+For detail on individual endpoints, please see the [_Detail_](#detail)
+section.
+
+### Errors
+
+Actionable failure conditions, covered in detail in their relevant sections,
+are reported as part of 4xx responses, in a json response body. One or more
+errors will be returned in the following format:
+
+ {
+ "errors:" [{
+ "code": ,
+ "message": ,
+ "detail":
+ },
+ ...
+ ]
+ }
+
+The `code` field will be a unique identifier, all caps with underscores by
+convention. The `message` field will be a human readable string. The optional
+`detail` field may contain arbitrary json data providing information the
+client can use to resolve the issue.
+
+While the client can take action on certain error codes, the registry may add
+new error codes over time. All client implementations should treat unknown
+error codes as `UNKNOWN`, allowing future error codes to be added without
+breaking API compatibility. For the purposes of the specification error codes
+will only be added and never removed.
+
+For a complete account of all error codes, please see the [_Errors_](#errors-2)
+section.
+
+### API Version Check
+
+A minimal endpoint, mounted at `/v2/` will provide version support information
+based on its response statuses. The request format is as follows:
+
+ GET /v2/
+
+If a `200 OK` response is returned, the registry implements the V2(.1)
+registry API and the client may proceed safely with other V2 operations.
+Optionally, the response may contain information about the supported paths in
+the response body. The client should be prepared to ignore this data.
+
+If a `401 Unauthorized` response is returned, the client should take action
+based on the contents of the "WWW-Authenticate" header and try the endpoint
+again. Depending on access control setup, the client may still have to
+authenticate against different resources, even if this check succeeds.
+
+If `404 Not Found` response status, or other unexpected status, is returned,
+the client should proceed with the assumption that the registry does not
+implement V2 of the API.
+
+When a `200 OK` or `401 Unauthorized` response is returned, the
+"Docker-Distribution-API-Version" header should be set to "registry/2.0".
+Clients may require this header value to determine if the endpoint serves this
+API. When this header is omitted, clients may fallback to an older API version.
+
+### Content Digests
+
+This API design is driven heavily by [content addressability](http://en.wikipedia.org/wiki/Content-addressable_storage).
+The core of this design is the concept of a content addressable identifier. It
+uniquely identifies content by taking a collision-resistant hash of the bytes.
+Such an identifier can be independently calculated and verified by selection
+of a common _algorithm_. If such an identifier can be communicated in a secure
+manner, one can retrieve the content from an insecure source, calculate it
+independently and be certain that the correct content was obtained. Put simply,
+the identifier is a property of the content.
+
+To disambiguate from other concepts, we call this identifier a _digest_. A
+_digest_ is a serialized hash result, consisting of a _algorithm_ and _hex_
+portion. The _algorithm_ identifies the methodology used to calculate the
+digest. The _hex_ portion is the hex-encoded result of the hash.
+
+We define a _digest_ string to match the following grammar:
+```
+digest := algorithm ":" hex
+algorithm := /[A-Fa-f0-9_+.-]+/
+hex := /[A-Fa-f0-9]+/
+```
+
+Some examples of _digests_ include the following:
+
+digest | description |
+----------------------------------------------------------------------------------|------------------------------------------------
+sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b | Common sha256 based digest |
+
+While the _algorithm_ does allow one to implement a wide variety of
+algorithms, compliant implementations should use sha256. Heavy processing of
+input before calculating a hash is discouraged to avoid degrading the
+uniqueness of the _digest_ but some canonicalization may be performed to
+ensure consistent identifiers.
+
+Let's use a simple example in pseudo-code to demonstrate a digest calculation:
+```
+let C = 'a small string'
+let B = sha256(C)
+let D = 'sha256:' + EncodeHex(B)
+let ID(C) = D
+```
+
+Above, we have bytestring `C` passed into a function, `SHA256`, that returns a
+bytestring `B`, which is the hash of `C`. `D` gets the algorithm concatenated
+with the hex encoding of `B`. We then define the identifier of `C` to `ID(C)`
+as equal to `D`. A digest can be verified by independently calculating `D` and
+comparing it with identifier `ID(C)`.
+
+#### Digest Header
+
+To provide verification of http content, any response may include a
+`Docker-Content-Digest` header. This will include the digest of the target
+entity returned in the response. For blobs, this is the entire blob content. For
+manifests, this is the manifest body without the signature content, also known
+as the JWS payload. Note that the commonly used canonicalization for digest
+calculation may be dependent on the mediatype of the content, such as with
+manifests.
+
+The client may choose to ignore the header or may verify it to ensure content
+integrity and transport security. This is most important when fetching by a
+digest. To ensure security, the content should be verified against the digest
+used to fetch the content. At times, the returned digest may differ from that
+used to initiate a request. Such digests are considered to be from different
+_domains_, meaning they have different values for _algorithm_. In such a case,
+the client may choose to verify the digests in both domains or ignore the
+server's digest. To maintain security, the client _must_ always verify the
+content against the _digest_ used to fetch the content.
+
+> __IMPORTANT:__ If a _digest_ is used to fetch content, the client should use
+> the same digest used to fetch the content to verify it. The header
+> `Docker-Content-Digest` should not be trusted over the "local" digest.
+
+### Pulling An Image
+
+An "image" is a combination of a JSON manifest and individual layer files. The
+process of pulling an image centers around retrieving these two components.
+
+The first step in pulling an image is to retrieve the manifest. For reference,
+the relevant manifest fields for the registry are the following:
+
+ field | description |
+----------|------------------------------------------------|
+name | The name of the image. |
+tag | The tag for this version of the image. |
+fsLayers | A list of layer descriptors (including digest) |
+signature | A JWS used to verify the manifest content |
+
+For more information about the manifest format, please see
+[docker/docker#8093](https://github.com/docker/docker/issues/8093).
+
+When the manifest is in hand, the client must verify the signature to ensure
+the names and layers are valid. Once confirmed, the client will then use the
+digests to download the individual layers. Layers are stored in as blobs in
+the V2 registry API, keyed by their digest.
+
+#### Pulling an Image Manifest
+
+The image manifest can be fetched with the following url:
+
+```
+GET /v2//manifests/
+```
+
+The `name` and `reference` parameter identify the image and are required. The
+reference may include a tag or digest.
+
+The client should include an Accept header indicating which manifest content
+types it supports. For more details on the manifest formats and their content
+types, see [manifest-v2-1.md](manifest-v2-1.md) and
+[manifest-v2-2.md](manifest-v2-2.md). In a successful response, the Content-Type
+header will indicate which manifest type is being returned.
+
+A `404 Not Found` response will be returned if the image is unknown to the
+registry. If the image exists and the response is successful, the image
+manifest will be returned, with the following format (see
+[docker/docker#8093](https://github.com/docker/docker/issues/8093) for details):
+
+ {
+ "name": ,
+ "tag": ,
+ "fsLayers": [
+ {
+ "blobSum":
+ },
+ ...
+ ]
+ ],
+ "history": ,
+ "signature":
+ }
+
+The client should verify the returned manifest signature for authenticity
+before fetching layers.
+
+##### Existing Manifests
+
+The image manifest can be checked for existence with the following url:
+
+```
+HEAD /v2//manifests/
+```
+
+The `name` and `reference` parameter identify the image and are required. The
+reference may include a tag or digest.
+
+A `404 Not Found` response will be returned if the image is unknown to the
+registry. If the image exists and the response is successful the response will
+be as follows:
+
+```
+200 OK
+Content-Length:
+Docker-Content-Digest:
+```
+
+
+#### Pulling a Layer
+
+Layers are stored in the blob portion of the registry, keyed by digest.
+Pulling a layer is carried out by a standard http request. The URL is as
+follows:
+
+ GET /v2//blobs/
+
+Access to a layer will be gated by the `name` of the repository but is
+identified uniquely in the registry by `digest`.
+
+This endpoint may issue a 307 (302 for /blobs/uploads/
+```
+
+The parameters of this request are the image namespace under which the layer
+will be linked. Responses to this request are covered below.
+
+##### Existing Layers
+
+The existence of a layer can be checked via a `HEAD` request to the blob store
+API. The request should be formatted as follows:
+
+```
+HEAD /v2//blobs/
+```
+
+If the layer with the digest specified in `digest` is available, a 200 OK
+response will be received, with no actual body content (this is according to
+http specification). The response will look as follows:
+
+```
+200 OK
+Content-Length:
+Docker-Content-Digest:
+```
+
+When this response is received, the client can assume that the layer is
+already available in the registry under the given name and should take no
+further action to upload the layer. Note that the binary digests may differ
+for the existing registry layer, but the digests will be guaranteed to match.
+
+##### Uploading the Layer
+
+If the POST request is successful, a `202 Accepted` response will be returned
+with the upload URL in the `Location` header:
+
+```
+202 Accepted
+Location: /v2//blobs/uploads/
+Range: bytes=0-
+Content-Length: 0
+Docker-Upload-UUID:
+```
+
+The rest of the upload process can be carried out with the returned url,
+called the "Upload URL" from the `Location` header. All responses to the
+upload url, whether sending data or getting status, will be in this format.
+Though the URI format (`/v2//blobs/uploads/`) for the `Location`
+header is specified, clients should treat it as an opaque url and should never
+try to assemble it. While the `uuid` parameter may be an actual UUID, this
+proposal imposes no constraints on the format and clients should never impose
+any.
+
+If clients need to correlate local upload state with remote upload state, the
+contents of the `Docker-Upload-UUID` header should be used. Such an id can be
+used to key the last used location header when implementing resumable uploads.
+
+##### Upload Progress
+
+The progress and chunk coordination of the upload process will be coordinated
+through the `Range` header. While this is a non-standard use of the `Range`
+header, there are examples of [similar approaches](https://developers.google.com/youtube/v3/guides/using_resumable_upload_protocol) in APIs with heavy use.
+For an upload that just started, for an example with a 1000 byte layer file,
+the `Range` header would be as follows:
+
+```
+Range: bytes=0-0
+```
+
+To get the status of an upload, issue a GET request to the upload URL:
+
+```
+GET /v2//blobs/uploads/
+Host:
+```
+
+The response will be similar to the above, except will return 204 status:
+
+```
+204 No Content
+Location: /v2//blobs/uploads/
+Range: bytes=0-
+Docker-Upload-UUID:
+```
+
+Note that the HTTP `Range` header byte ranges are inclusive and that will be
+honored, even in non-standard use cases.
+
+##### Monolithic Upload
+
+A monolithic upload is simply a chunked upload with a single chunk and may be
+favored by clients that would like to avoided the complexity of chunking. To
+carry out a "monolithic" upload, one can simply put the entire content blob to
+the provided URL:
+
+```
+PUT /v2//blobs/uploads/?digest=
+Content-Length:
+Content-Type: application/octet-stream
+
+
+```
+
+The "digest" parameter must be included with the PUT request. Please see the
+[_Completed Upload_](#completed-upload) section for details on the parameters
+and expected responses.
+
+##### Chunked Upload
+
+To carry out an upload of a chunk, the client can specify a range header and
+only include that part of the layer file:
+
+```
+PATCH /v2//blobs/uploads/
+Content-Length:
+Content-Range: -
+Content-Type: application/octet-stream
+
+
+```
+
+There is no enforcement on layer chunk splits other than that the server must
+receive them in order. The server may enforce a minimum chunk size. If the
+server cannot accept the chunk, a `416 Requested Range Not Satisfiable`
+response will be returned and will include a `Range` header indicating the
+current status:
+
+```
+416 Requested Range Not Satisfiable
+Location: /v2//blobs/uploads/
+Range: 0-
+Content-Length: 0
+Docker-Upload-UUID:
+```
+
+If this response is received, the client should resume from the "last valid
+range" and upload the subsequent chunk. A 416 will be returned under the
+following conditions:
+
+- Invalid Content-Range header format
+- Out of order chunk: the range of the next chunk must start immediately after
+ the "last valid range" from the previous response.
+
+When a chunk is accepted as part of the upload, a `202 Accepted` response will
+be returned, including a `Range` header with the current upload status:
+
+```
+202 Accepted
+Location: /v2//blobs/uploads/
+Range: bytes=0-
+Content-Length: 0
+Docker-Upload-UUID:
+```
+
+##### Completed Upload
+
+For an upload to be considered complete, the client must submit a `PUT`
+request on the upload endpoint with a digest parameter. If it is not provided,
+the upload will not be considered complete. The format for the final chunk
+will be as follows:
+
+```
+PUT /v2//blobs/uploads/?digest=
+Content-Length:
+Content-Range: -
+Content-Type: application/octet-stream
+
+
+```
+
+Optionally, if all chunks have already been uploaded, a `PUT` request with a
+`digest` parameter and zero-length body may be sent to complete and validate
+the upload. Multiple "digest" parameters may be provided with different
+digests. The server may verify none or all of them but _must_ notify the
+client if the content is rejected.
+
+When the last chunk is received and the layer has been validated, the client
+will receive a `201 Created` response:
+
+```
+201 Created
+Location: /v2//blobs/
+Content-Length: 0
+Docker-Content-Digest:
+```
+
+The `Location` header will contain the registry URL to access the accepted
+layer file. The `Docker-Content-Digest` header returns the canonical digest of
+the uploaded blob which may differ from the provided digest. Most clients may
+ignore the value but if it is used, the client should verify the value against
+the uploaded blob data.
+
+###### Digest Parameter
+
+The "digest" parameter is designed as an opaque parameter to support
+verification of a successful transfer. For example, an HTTP URI parameter
+might be as follows:
+
+```
+sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b
+```
+
+Given this parameter, the registry will verify that the provided content does
+match this digest.
+
+##### Canceling an Upload
+
+An upload can be cancelled by issuing a DELETE request to the upload endpoint.
+The format will be as follows:
+
+```
+DELETE /v2//blobs/uploads/
+```
+
+After this request is issued, the upload uuid will no longer be valid and the
+registry server will dump all intermediate data. While uploads will time out
+if not completed, clients should issue this request if they encounter a fatal
+error but still have the ability to issue an http request.
+
+##### Cross Repository Blob Mount
+
+A blob may be mounted from another repository that the client has read access
+to, removing the need to upload a blob already known to the registry. To issue
+a blob mount instead of an upload, a POST request should be issued in the
+following format:
+
+```
+POST /v2//blobs/uploads/?mount=&from=
+Content-Length: 0
+```
+
+If the blob is successfully mounted, the client will receive a `201 Created`
+response:
+
+```
+201 Created
+Location: /v2//blobs/
+Content-Length: 0
+Docker-Content-Digest:
+```
+
+The `Location` header will contain the registry URL to access the accepted
+layer file. The `Docker-Content-Digest` header returns the canonical digest of
+the uploaded blob which may differ from the provided digest. Most clients may
+ignore the value but if it is used, the client should verify the value against
+the uploaded blob data.
+
+If a mount fails due to invalid repository or digest arguments, the registry
+will fall back to the standard upload behavior and return a `202 Accepted` with
+the upload URL in the `Location` header:
+
+```
+202 Accepted
+Location: /v2//blobs/uploads/
+Range: bytes=0-
+Content-Length: 0
+Docker-Upload-UUID:
+```
+
+This behavior is consistent with older versions of the registry, which do not
+recognize the repository mount query parameters.
+
+Note: a client may issue a HEAD request to check existence of a blob in a source
+repository to distinguish between the registry not supporting blob mounts and
+the blob not existing in the expected repository.
+
+##### Errors
+
+If an 502, 503 or 504 error is received, the client should assume that the
+download can proceed due to a temporary condition, honoring the appropriate
+retry mechanism. Other 5xx errors should be treated as terminal.
+
+If there is a problem with the upload, a 4xx error will be returned indicating
+the problem. After receiving a 4xx response (except 416, as called out above),
+the upload will be considered failed and the client should take appropriate
+action.
+
+Note that the upload url will not be available forever. If the upload uuid is
+unknown to the registry, a `404 Not Found` response will be returned and the
+client must restart the upload process.
+
+#### Deleting a Layer
+
+A layer may be deleted from the registry via its `name` and `digest`. A
+delete may be issued with the following request format:
+
+ DELETE /v2//blobs/
+
+If the blob exists and has been successfully deleted, the following response
+will be issued:
+
+ 202 Accepted
+ Content-Length: None
+
+If the blob had already been deleted or did not exist, a `404 Not Found`
+response will be issued instead.
+
+If a layer is deleted which is referenced by a manifest in the registry,
+then the complete images will not be resolvable.
+
+#### Pushing an Image Manifest
+
+Once all of the layers for an image are uploaded, the client can upload the
+image manifest. An image can be pushed using the following request format:
+
+ PUT /v2//manifests/
+ Content-Type:
+
+ {
+ "name": ,
+ "tag": ,
+ "fsLayers": [
+ {
+ "blobSum":
+ },
+ ...
+ ]
+ ],
+ "history": ,
+ "signature": ,
+ ...
+ }
+
+The `name` and `reference` fields of the response body must match those
+specified in the URL. The `reference` field may be a "tag" or a "digest". The
+content type should match the type of the manifest being uploaded, as specified
+in [manifest-v2-1.md](manifest-v2-1.md) and [manifest-v2-2.md](manifest-v2-2.md).
+
+If there is a problem with pushing the manifest, a relevant 4xx response will
+be returned with a JSON error message. Please see the
+[_PUT Manifest_](#put-manifest) section for details on possible error codes that
+may be returned.
+
+If one or more layers are unknown to the registry, `BLOB_UNKNOWN` errors are
+returned. The `detail` field of the error response will have a `digest` field
+identifying the missing blob. An error is returned for each unknown blob. The
+response format is as follows:
+
+ {
+ "errors:" [{
+ "code": "BLOB_UNKNOWN",
+ "message": "blob unknown to registry",
+ "detail": {
+ "digest":
+ }
+ },
+ ...
+ ]
+ }
+
+### Listing Repositories
+
+Images are stored in collections, known as a _repository_, which is keyed by a
+`name`, as seen throughout the API specification. A registry instance may
+contain several repositories. The list of available repositories is made
+available through the _catalog_.
+
+The catalog for a given registry can be retrieved with the following request:
+
+```
+GET /v2/_catalog
+```
+
+The response will be in the following format:
+
+```
+200 OK
+Content-Type: application/json
+
+{
+ "repositories": [
+ ,
+ ...
+ ]
+}
+```
+
+Note that the contents of the response are specific to the registry
+implementation. Some registries may opt to provide a full catalog output,
+limit it based on the user's access level or omit upstream results, if
+providing mirroring functionality. Subsequently, the presence of a repository
+in the catalog listing only means that the registry *may* provide access to
+the repository at the time of the request. Conversely, a missing entry does
+*not* mean that the registry does not have the repository. More succinctly,
+the presence of a repository only guarantees that it is there but not that it
+is _not_ there.
+
+For registries with a large number of repositories, this response may be quite
+large. If such a response is expected, one should use pagination. A registry
+may also limit the amount of responses returned even if pagination was not
+explicitly requested. In this case the `Link` header will be returned along
+with the results, and subsequent results can be obtained by following the link
+as if pagination had been initially requested.
+
+For details of the `Link` header, please see the [_Pagination_](#pagination)
+section.
+
+#### Pagination
+
+Paginated catalog results can be retrieved by adding an `n` parameter to the
+request URL, declaring that the response should be limited to `n` results.
+Starting a paginated flow begins as follows:
+
+```
+GET /v2/_catalog?n=
+```
+
+The above specifies that a catalog response should be returned, from the start of
+the result set, ordered lexically, limiting the number of results to `n`. The
+response to such a request would look as follows:
+
+```
+200 OK
+Content-Type: application/json
+Link: <?n=&last=>; rel="next"
+
+{
+ "repositories": [
+ ,
+ ...
+ ]
+}
+```
+
+The above includes the _first_ `n` entries from the result set. To get the
+_next_ `n` entries, one can create a URL where the argument `last` has the
+value from `repositories[len(repositories)-1]`. If there are indeed more
+results, the URL for the next block is encoded in an
+[RFC5988](https://tools.ietf.org/html/rfc5988) `Link` header, as a "next"
+relation. The presence of the `Link` header communicates to the client that
+the entire result set has not been returned and another request must be
+issued. If the header is not present, the client can assume that all results
+have been received.
+
+> __NOTE:__ In the request template above, note that the brackets
+> are required. For example, if the url is
+> `http://example.com/v2/_catalog?n=20&last=b`, the value of the header would
+> be `; rel="next"`. Please see
+> [RFC5988](https://tools.ietf.org/html/rfc5988) for details.
+
+Compliant client implementations should always use the `Link` header
+value when proceeding through results linearly. The client may construct URLs
+to skip forward in the catalog.
+
+To get the next result set, a client would issue the request as follows, using
+the URL encoded in the described `Link` header:
+
+```
+GET /v2/_catalog?n=&last=
+```
+
+The above process should then be repeated until the `Link` header is no longer
+set.
+
+The catalog result set is represented abstractly as a lexically sorted list,
+where the position in that list can be specified by the query term `last`. The
+entries in the response start _after_ the term specified by `last`, up to `n`
+entries.
+
+The behavior of `last` is quite simple when demonstrated with an example. Let
+us say the registry has the following repositories:
+
+```
+a
+b
+c
+d
+```
+
+If the value of `n` is 2, _a_ and _b_ will be returned on the first response.
+The `Link` header returned on the response will have `n` set to 2 and last set
+to _b_:
+
+```
+Link: <?n=2&last=b>; rel="next"
+```
+
+The client can then issue the request with the above value from the `Link`
+header, receiving the values _c_ and _d_. Note that `n` may change on the second
+to last response or be fully omitted, depending on the server implementation.
+
+### Listing Image Tags
+
+It may be necessary to list all of the tags under a given repository. The tags
+for an image repository can be retrieved with the following request:
+
+ GET /v2//tags/list
+
+The response will be in the following format:
+
+ 200 OK
+ Content-Type: application/json
+
+ {
+ "name": ,
+ "tags": [
+ ,
+ ...
+ ]
+ }
+
+For repositories with a large number of tags, this response may be quite
+large. If such a response is expected, one should use the pagination.
+
+#### Pagination
+
+Paginated tag results can be retrieved by adding the appropriate parameters to
+the request URL described above. The behavior of tag pagination is identical
+to that specified for catalog pagination. We cover a simple flow to highlight
+any differences.
+
+Starting a paginated flow may begin as follows:
+
+```
+GET /v2//tags/list?n=
+```
+
+The above specifies that a tags response should be returned, from the start of
+the result set, ordered lexically, limiting the number of results to `n`. The
+response to such a request would look as follows:
+
+```
+200 OK
+Content-Type: application/json
+Link: <?n=&last=>; rel="next"
+
+{
+ "name": ,
+ "tags": [
+ ,
+ ...
+ ]
+}
+```
+
+To get the next result set, a client would issue the request as follows, using
+the value encoded in the [RFC5988](https://tools.ietf.org/html/rfc5988) `Link`
+header:
+
+```
+GET /v2//tags/list?n=&last=
+```
+
+The above process should then be repeated until the `Link` header is no longer
+set in the response. The behavior of the `last` parameter, the provided
+response result, lexical ordering and encoding of the `Link` header are
+identical to that of catalog pagination.
+
+### Deleting an Image
+
+An image may be deleted from the registry via its `name` and `reference`. A
+delete may be issued with the following request format:
+
+ DELETE /v2//manifests/
+
+For deletes, `reference` *must* be a digest or the delete will fail. If the
+image exists and has been successfully deleted, the following response will be
+issued:
+
+ 202 Accepted
+ Content-Length: None
+
+If the image had already been deleted or did not exist, a `404 Not Found`
+response will be issued instead.
+
+> **Note** When deleting a manifest from a registry version 2.3 or later, the
+> following header must be used when `HEAD` or `GET`-ing the manifest to obtain
+> the correct digest to delete:
+
+ Accept: application/vnd.docker.distribution.manifest.v2+json
+
+> for more details, see: [compatibility.md](../compatibility.md#content-addressable-storage-cas)
+
+## Detail
+
+> **Note**: This section is still under construction. For the purposes of
+> implementation, if any details below differ from the described request flows
+> above, the section below should be corrected. When they match, this note
+> should be removed.
+
+The behavior of the endpoints are covered in detail in this section, organized
+by route and entity. All aspects of the request and responses are covered,
+including headers, parameters and body formats. Examples of requests and their
+corresponding responses, with success and failure, are enumerated.
+
+> **Note**: The sections on endpoint detail are arranged with an example
+> request, a description of the request, followed by information about that
+> request.
+
+A list of methods and URIs are covered in the table below:
+
+|Method|Path|Entity|Description|
+|------|----|------|-----------|
+| GET | `/v2/` | Base | Check that the endpoint implements Docker Registry API V2. |
+| GET | `/v2//tags/list` | Tags | Fetch the tags under the repository identified by `name`. |
+| GET | `/v2//manifests/` | Manifest | Fetch the manifest identified by `name` and `reference` where `reference` can be a tag or digest. A `HEAD` request can also be issued to this endpoint to obtain resource information without receiving all data. |
+| PUT | `/v2//manifests/` | Manifest | Put the manifest identified by `name` and `reference` where `reference` can be a tag or digest. |
+| DELETE | `/v2//manifests/` | Manifest | Delete the manifest identified by `name` and `reference`. Note that a manifest can _only_ be deleted by `digest`. |
+| GET | `/v2//blobs/` | Blob | Retrieve the blob from the registry identified by `digest`. A `HEAD` request can also be issued to this endpoint to obtain resource information without receiving all data. |
+| DELETE | `/v2//blobs/` | Blob | Delete the blob identified by `name` and `digest` |
+| POST | `/v2//blobs/uploads/` | Initiate Blob Upload | Initiate a resumable blob upload. If successful, an upload location will be provided to complete the upload. Optionally, if the `digest` parameter is present, the request body will be used to complete the upload in a single request. |
+| GET | `/v2//blobs/uploads/` | Blob Upload | Retrieve status of upload identified by `uuid`. The primary purpose of this endpoint is to resolve the current status of a resumable upload. |
+| PATCH | `/v2//blobs/uploads/` | Blob Upload | Upload a chunk of data for the specified upload. |
+| PUT | `/v2//blobs/uploads/` | Blob Upload | Complete the upload specified by `uuid`, optionally appending the body as the final chunk. |
+| DELETE | `/v2//blobs/uploads/` | Blob Upload | Cancel outstanding upload processes, releasing associated resources. If this is not called, the unfinished uploads will eventually timeout. |
+| GET | `/v2/_catalog` | Catalog | Retrieve a sorted, json list of repositories available in the registry. |
+
+
+The detail for each endpoint is covered in the following sections.
+
+### Errors
+
+The error codes encountered via the API are enumerated in the following table:
+
+|Code|Message|Description|
+|----|-------|-----------|
+ `BLOB_UNKNOWN` | blob unknown to registry | This error may be returned when a blob is unknown to the registry in a specified repository. This can be returned with a standard get or if a manifest references an unknown layer during upload.
+ `BLOB_UPLOAD_INVALID` | blob upload invalid | The blob upload encountered an error and can no longer proceed.
+ `BLOB_UPLOAD_UNKNOWN` | blob upload unknown to registry | If a blob upload has been cancelled or was never started, this error code may be returned.
+ `DIGEST_INVALID` | provided digest did not match uploaded content | When a blob is uploaded, the registry will check that the content matches the digest provided by the client. The error may include a detail structure with the key "digest", including the invalid digest string. This error may also be returned when a manifest includes an invalid layer digest.
+ `MANIFEST_BLOB_UNKNOWN` | blob unknown to registry | This error may be returned when a manifest blob is unknown to the registry.
+ `MANIFEST_INVALID` | manifest invalid | During upload, manifests undergo several checks ensuring validity. If those checks fail, this error may be returned, unless a more specific error is included. The detail will contain information the failed validation.
+ `MANIFEST_UNKNOWN` | manifest unknown | This error is returned when the manifest, identified by name and tag is unknown to the repository.
+ `MANIFEST_UNVERIFIED` | manifest failed signature verification | During manifest upload, if the manifest fails signature verification, this error will be returned.
+ `NAME_INVALID` | invalid repository name | Invalid repository name encountered either during manifest validation or any API operation.
+ `NAME_UNKNOWN` | repository name not known to registry | This is returned if the name used during an operation is unknown to the registry.
+ `SIZE_INVALID` | provided length did not match content length | When a layer is uploaded, the provided size will be checked against the uploaded content. If they do not match, this error will be returned.
+ `TAG_INVALID` | manifest tag did not match URI | During a manifest upload, if the tag in the manifest does not match the uri tag, this error will be returned.
+ `UNAUTHORIZED` | authentication required | The access controller was unable to authenticate the client. Often this will be accompanied by a Www-Authenticate HTTP response header indicating how to authenticate.
+ `DENIED` | requested access to the resource is denied | The access controller denied access for the operation on a resource.
+ `UNSUPPORTED` | The operation is unsupported. | The operation was unsupported due to a missing implementation or invalid set of parameters.
+
+
+
+### Base
+
+Base V2 API route. Typically, this can be used for lightweight version checks and to validate registry authentication.
+
+
+
+#### GET Base
+
+Check that the endpoint implements Docker Registry API V2.
+
+
+
+```
+GET /v2/
+Host:
+Authorization:
+```
+
+
+
+
+The following parameters should be specified on the request:
+
+|Name|Kind|Description|
+|----|----|-----------|
+|`Host`|header|Standard HTTP Host Header. Should be set to the registry host.|
+|`Authorization`|header|An RFC7235 compliant authorization header.|
+
+
+
+
+###### On Success: OK
+
+```
+200 OK
+```
+
+The API implements V2 protocol and is accessible.
+
+
+
+
+###### On Failure: Not Found
+
+```
+404 Not Found
+```
+
+The registry does not implement the V2 API.
+
+
+
+###### On Failure: Authentication Required
+
+```
+401 Unauthorized
+WWW-Authenticate: realm="", ..."
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client is not authenticated.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`WWW-Authenticate`|An RFC7235 compliant authentication challenge header.|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `UNAUTHORIZED` | authentication required | The access controller was unable to authenticate the client. Often this will be accompanied by a Www-Authenticate HTTP response header indicating how to authenticate. |
+
+
+
+###### On Failure: Too Many Requests
+
+```
+429 Too Many Requests
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client made too many requests within a time interval.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `TOOMANYREQUESTS` | too many requests | Returned when a client attempts to contact a service too many times |
+
+
+
+
+
+### Tags
+
+Retrieve information about tags.
+
+
+
+#### GET Tags
+
+Fetch the tags under the repository identified by `name`.
+
+
+##### Tags
+
+```
+GET /v2//tags/list
+Host:
+Authorization:
+```
+
+Return all tags for the repository
+
+
+The following parameters should be specified on the request:
+
+|Name|Kind|Description|
+|----|----|-----------|
+|`Host`|header|Standard HTTP Host Header. Should be set to the registry host.|
+|`Authorization`|header|An RFC7235 compliant authorization header.|
+|`name`|path|Name of the target repository.|
+
+
+
+
+###### On Success: OK
+
+```
+200 OK
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "name": ,
+ "tags": [
+ ,
+ ...
+ ]
+}
+```
+
+A list of tags for the named repository.
+
+The following headers will be returned with the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+
+###### On Failure: Authentication Required
+
+```
+401 Unauthorized
+WWW-Authenticate: realm="", ..."
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client is not authenticated.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`WWW-Authenticate`|An RFC7235 compliant authentication challenge header.|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `UNAUTHORIZED` | authentication required | The access controller was unable to authenticate the client. Often this will be accompanied by a Www-Authenticate HTTP response header indicating how to authenticate. |
+
+
+
+###### On Failure: No Such Repository Error
+
+```
+404 Not Found
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The repository is not known to the registry.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `NAME_UNKNOWN` | repository name not known to registry | This is returned if the name used during an operation is unknown to the registry. |
+
+
+
+###### On Failure: Access Denied
+
+```
+403 Forbidden
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client does not have required access to the repository.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `DENIED` | requested access to the resource is denied | The access controller denied access for the operation on a resource. |
+
+
+
+###### On Failure: Too Many Requests
+
+```
+429 Too Many Requests
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client made too many requests within a time interval.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `TOOMANYREQUESTS` | too many requests | Returned when a client attempts to contact a service too many times |
+
+
+
+##### Tags Paginated
+
+```
+GET /v2//tags/list?n=&last=
+```
+
+Return a portion of the tags for the specified repository.
+
+
+The following parameters should be specified on the request:
+
+|Name|Kind|Description|
+|----|----|-----------|
+|`name`|path|Name of the target repository.|
+|`n`|query|Limit the number of entries in each response. It not present, all entries will be returned.|
+|`last`|query|Result set will include values lexically after last.|
+
+
+
+
+###### On Success: OK
+
+```
+200 OK
+Content-Length:
+Link: <?n=&last=>; rel="next"
+Content-Type: application/json; charset=utf-8
+
+{
+ "name": ,
+ "tags": [
+ ,
+ ...
+ ],
+}
+```
+
+A list of tags for the named repository.
+
+The following headers will be returned with the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|
+
+
+
+
+###### On Failure: Authentication Required
+
+```
+401 Unauthorized
+WWW-Authenticate: realm="", ..."
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client is not authenticated.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`WWW-Authenticate`|An RFC7235 compliant authentication challenge header.|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `UNAUTHORIZED` | authentication required | The access controller was unable to authenticate the client. Often this will be accompanied by a Www-Authenticate HTTP response header indicating how to authenticate. |
+
+
+
+###### On Failure: No Such Repository Error
+
+```
+404 Not Found
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The repository is not known to the registry.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `NAME_UNKNOWN` | repository name not known to registry | This is returned if the name used during an operation is unknown to the registry. |
+
+
+
+###### On Failure: Access Denied
+
+```
+403 Forbidden
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client does not have required access to the repository.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `DENIED` | requested access to the resource is denied | The access controller denied access for the operation on a resource. |
+
+
+
+###### On Failure: Too Many Requests
+
+```
+429 Too Many Requests
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client made too many requests within a time interval.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `TOOMANYREQUESTS` | too many requests | Returned when a client attempts to contact a service too many times |
+
+
+
+
+
+### Manifest
+
+Create, update, delete and retrieve manifests.
+
+
+
+#### GET Manifest
+
+Fetch the manifest identified by `name` and `reference` where `reference` can be a tag or digest. A `HEAD` request can also be issued to this endpoint to obtain resource information without receiving all data.
+
+
+
+```
+GET /v2//manifests/
+Host:
+Authorization:
+```
+
+
+
+
+The following parameters should be specified on the request:
+
+|Name|Kind|Description|
+|----|----|-----------|
+|`Host`|header|Standard HTTP Host Header. Should be set to the registry host.|
+|`Authorization`|header|An RFC7235 compliant authorization header.|
+|`name`|path|Name of the target repository.|
+|`reference`|path|Tag or digest of the target manifest.|
+
+
+
+
+###### On Success: OK
+
+```
+200 OK
+Docker-Content-Digest:
+Content-Type:
+
+{
+ "name": ,
+ "tag": ,
+ "fsLayers": [
+ {
+ "blobSum": ""
+ },
+ ...
+ ]
+ ],
+ "history": ,
+ "signature":
+}
+```
+
+The manifest identified by `name` and `reference`. The contents can be used to identify and resolve resources required to run the specified image.
+
+The following headers will be returned with the response:
+
+|Name|Description|
+|----|-----------|
+|`Docker-Content-Digest`|Digest of the targeted content for the request.|
+
+
+
+
+###### On Failure: Bad Request
+
+```
+400 Bad Request
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The name or reference was invalid.
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `NAME_INVALID` | invalid repository name | Invalid repository name encountered either during manifest validation or any API operation. |
+| `TAG_INVALID` | manifest tag did not match URI | During a manifest upload, if the tag in the manifest does not match the uri tag, this error will be returned. |
+
+
+
+###### On Failure: Authentication Required
+
+```
+401 Unauthorized
+WWW-Authenticate: realm="", ..."
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client is not authenticated.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`WWW-Authenticate`|An RFC7235 compliant authentication challenge header.|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `UNAUTHORIZED` | authentication required | The access controller was unable to authenticate the client. Often this will be accompanied by a Www-Authenticate HTTP response header indicating how to authenticate. |
+
+
+
+###### On Failure: No Such Repository Error
+
+```
+404 Not Found
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The repository is not known to the registry.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `NAME_UNKNOWN` | repository name not known to registry | This is returned if the name used during an operation is unknown to the registry. |
+
+
+
+###### On Failure: Access Denied
+
+```
+403 Forbidden
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client does not have required access to the repository.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `DENIED` | requested access to the resource is denied | The access controller denied access for the operation on a resource. |
+
+
+
+###### On Failure: Too Many Requests
+
+```
+429 Too Many Requests
+Content-Length:
+Content-Type: application/json; charset=utf-8
+
+{
+ "errors:" [
+ {
+ "code": ,
+ "message": "",
+ "detail": ...
+ },
+ ...
+ ]
+}
+```
+
+The client made too many requests within a time interval.
+
+The following headers will be returned on the response:
+
+|Name|Description|
+|----|-----------|
+|`Content-Length`|Length of the JSON response body.|
+
+
+
+The error codes that may be included in the response body are enumerated below:
+
+|Code|Message|Description|
+|----|-------|-----------|
+| `TOOMANYREQUESTS` | too many requests | Returned when a client attempts to contact a service too many times |
+
+
+
+
+#### PUT Manifest
+
+Put the manifest identified by `name` and `reference` where `reference` can be a tag or digest.
+
+
+
+```
+PUT /v2//manifests/
+Host:
+Authorization:
+Content-Type:
+
+{
+ "name": ,
+ "tag":
- 
-
-
diff --git a/_includes/landing-page/community-banner.html b/_includes/landing-page/community-banner.html
deleted file mode 100644
index 75878d4048..0000000000
--- a/_includes/landing-page/community-banner.html
+++ /dev/null
@@ -1,21 +0,0 @@
-
diff --git a/_includes/landing-page/dev-environments.html b/_includes/landing-page/dev-environments.html
deleted file mode 100644
index 2aa3de0298..0000000000
--- a/_includes/landing-page/dev-environments.html
+++ /dev/null
@@ -1,19 +0,0 @@
-
diff --git a/_includes/landing-page/develop-with-docker.html b/_includes/landing-page/develop-with-docker.html
deleted file mode 100644
index f294bca7d7..0000000000
--- a/_includes/landing-page/develop-with-docker.html
+++ /dev/null
@@ -1,37 +0,0 @@
-
-
-
-
- 
- 
- 
-
-
-
- 
-
-
-
- Learn more
-
-
-
- 
-
-
-
-
-
-
-
diff --git a/_includes/release-date.html b/_includes/release-date.html
deleted file mode 100644
index d84e2cb76e..0000000000
--- a/_includes/release-date.html
+++ /dev/null
@@ -1 +0,0 @@
-{{ include.date }}
\ No newline at end of file
diff --git a/_includes/theme-switch.html b/_includes/theme-switch.html
deleted file mode 100644
index f21b3a0cf8..0000000000
--- a/_includes/theme-switch.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
diff --git a/_includes/toc_pure_liquid.html b/_includes/toc_pure_liquid.html
deleted file mode 100644
index cd1a2ed60a..0000000000
--- a/_includes/toc_pure_liquid.html
+++ /dev/null
@@ -1,68 +0,0 @@
-{% capture tocWorkspace %}
- {% comment %}
- "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
- Usage:
- {% include toc_pure_liquid.html html=content sanitize=true class="inline_toc" id="my_toc" toc_min=2 toc_max=3 %}
-
- Variables:
- * html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
- * sanitize (bool) - when set to true, the headers will be sanitized in the TOC
- * class (string) - a CSS class assigned to the TOC
- * id (string) - an ID to assigned to the TOC
- * toc_min (int) - the minimum TOC header level to use (if not set, check page, then site, then default to 2)
- * toc_max (int) - the maximum TOC header level to use (if not set, check page, then site, then default to 3)
-
- Output:
- An unordered list representing the table of contents of a markdown block. This snippet will only generate the table of contents and will NOT output the markdown given to it
- {% endcomment %}
-
- {% capture my_toc %}{% endcapture %}
- {% assign minHeader = include.toc_min | default: 2 %}
- {% assign maxHeader = include.toc_max | default: 3 %}
- {% assign nodes = include.html | split: '