librewolf
/
bunkerized-nginx
mirror of https://github.com/bunkerity/bunkerized-nginx
4
0
Fork 1
Code Issues Projects Releases Wiki Activity

use current_bw_version for docs, add automatic tests to ui branch and fix letsencrypt permissions for linux

This commit is contained in:
florian 2023-04-29 16:47:28 +02:00
parent 58fd04430e
commit 14a4db8bdb
No known key found for this signature in database
GPG Key ID: 3D80806F12602A7C
20 changed files with 821 additions and 446 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
.github/workflows/beta.yml vendored
View File

@ -15,6 +15,8 @@ jobs:
ARCH: linux/amd64
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -27,6 +29,8 @@ jobs:
ARCH: linux/386
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -41,6 +45,8 @@ jobs:
ARCH: linux/amd64
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -53,6 +59,8 @@ jobs:
ARCH: linux/386
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -67,6 +75,8 @@ jobs:
ARCH: linux/amd64
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -79,6 +89,8 @@ jobs:
ARCH: linux/386
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -93,6 +105,8 @@ jobs:
ARCH: linux/amd64
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -105,6 +119,8 @@ jobs:
ARCH: linux/386
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -119,6 +135,8 @@ jobs:
ARCH: linux/arm64,linux/arm/v7
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -132,6 +150,8 @@ jobs:
ARCH: linux/arm64,linux/arm/v7
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -145,6 +165,8 @@ jobs:
ARCH: linux/arm64,linux/arm/v7
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
@ -158,6 +180,8 @@ jobs:
ARCH: linux/arm64,linux/arm/v7
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}

27
.github/workflows/container-build.yml vendored
View File

@ -15,15 +15,23 @@ on:
DOCKERFILE:
required: true
type: string
CACHE:
required: false
type: boolean
default: true
PUSH:
required: false
type: boolean
default: true
secrets:
DOCKER_USERNAME:
required: true
DOCKER_TOKEN:
required: true
PRIVATE_REGISTRY:
required: true
required: false
PRIVATE_REGISTRY_TOKEN:
required: true
required: false
jobs:
build:
@ -40,14 +48,15 @@ jobs:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_TOKEN }}
- name: Login to private repository
if: inputs.RELEASE == 'staging'
uses: docker/login-action@v2
with:
registry: ${{ secrets.PRIVATE_REGISTRY }}
username: registry
password: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# Build staging image
# Build cached image
- name: Build image
if: inputs.RELEASE == 'staging'
if: inputs.CACHE == true
uses: docker/build-push-action@v3
with:
context: .
@ -55,11 +64,11 @@ jobs:
platforms: ${{ inputs.ARCH }}
load: true
tags: local/${{ inputs.IMAGE }}
cache-from: type=registry,ref=bunkerity/cache:${{ inputs.IMAGE }}-staging
cache-to: type=registry,ref=bunkerity/cache:${{ inputs.IMAGE }}-staging,mode=min
# Build non-staging image
cache-from: type=registry,ref=bunkerity/cache:${{ inputs.IMAGE }}-${{ inputs.RELEASE }}
cache-to: type=registry,ref=bunkerity/cache:${{ inputs.IMAGE }}-${{ inputs.RELEASE }},mode=min
# Build non-cached image
- name: Build image
if: inputs.RELEASE != 'staging'
if: if: inputs.CACHE != true
uses: docker/build-push-action@v3
with:
context: .
@ -81,7 +90,7 @@ jobs:
trivyignores: .trivyignore
# Push image
- name: Push image
if: inputs.RELEASE == 'staging'
if: inputs.PUSH == true
run: docker tag local/${{ inputs.IMAGE }} ${{ secrets.PRIVATE_REGISTRY }}/infra/${{ inputs.IMAGE }}-tests:$TAG && docker push ${{ secrets.PRIVATE_REGISTRY }}/infra/${{ inputs.IMAGE }}-tests:$TAG
env:
TAG: "${{ inputs.RELEASE }}"

234
.github/workflows/dev.yml vendored
View File

@ -7,182 +7,56 @@ on:
branches: [dev]
jobs:
# BW dev tests
bw:
runs-on: ubuntu-latest
steps:
# Prepare
- name: Checkout source code
uses: actions/checkout@v3
- name: Setup Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_TOKEN }}
- name: Login to private repository
uses: docker/login-action@v2
with:
registry: ${{ secrets.PRIVATE_REGISTRY }}
username: registry
password: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# Build image
- name: Build image
uses: docker/build-push-action@v3
with:
context: .
file: src/bw/Dockerfile
platforms: linux/amd64
load: true
#push: true
tags: local/bw:dev
cache-from: type=registry,ref=bunkerity/cache:dev-bw-amd64-cache
cache-to: type=registry,ref=bunkerity/cache:dev-bw-amd64-cache,mode=min
# Check OS vulnerabilities
- name: Check OS vulnerabilities
uses: aquasecurity/trivy-action@master
with:
vuln-type: os
image-ref: local/bw:dev
format: table
exit-code: 1
ignore-unfixed: false
severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
# trivyignores: .trivyignore
# BW scheduler tests
scheduler:
runs-on: ubuntu-latest
steps:
# Prepare
- name: Checkout source code
uses: actions/checkout@v3
- name: Setup Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_TOKEN }}
- name: Login to private repository
uses: docker/login-action@v2
with:
registry: ${{ secrets.PRIVATE_REGISTRY }}
username: registry
password: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# Build image
- name: Build image
uses: docker/build-push-action@v3
with:
context: .
file: src/scheduler/Dockerfile
platforms: linux/amd64
load: true
#push: true
tags: local/scheduler:dev
cache-from: type=registry,ref=bunkerity/cache:dev-scheduler-amd64-cache
cache-to: type=registry,ref=bunkerity/cache:dev-scheduler-amd64-cache,mode=min
# Check OS vulnerabilities
- name: Check OS vulnerabilities
uses: aquasecurity/trivy-action@master
with:
vuln-type: os
image-ref: local/scheduler:dev
format: table
exit-code: 1
ignore-unfixed: false
severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
# trivyignores: .trivyignore
# BW autoconf tests
autoconf:
runs-on: ubuntu-latest
steps:
# Prepare
- name: Checkout source code
uses: actions/checkout@v3
- name: Setup Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_TOKEN }}
- name: Login to private repository
uses: docker/login-action@v2
with:
registry: ${{ secrets.PRIVATE_REGISTRY }}
username: registry
password: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# Build image
- name: Build image
uses: docker/build-push-action@v3
with:
context: .
file: src/autoconf/Dockerfile
platforms: linux/amd64
load: true
#push: true
tags: local/autoconf:dev
cache-from: type=registry,ref=bunkerity/cache:dev-ui-amd64-cache
cache-to: type=registry,ref=bunkerity/cache:dev-ui-amd64-cache,mode=min
# Check OS vulnerabilities
- name: Check OS vulnerabilities
uses: aquasecurity/trivy-action@master
with:
vuln-type: os
image-ref: local/autoconf:dev
format: table
exit-code: 1
ignore-unfixed: false
severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
# trivyignores: .trivyignore
# BW UI tests
ui:
runs-on: ubuntu-latest
steps:
# Prepare
- name: Checkout source code
uses: actions/checkout@v3
- name: Setup Buildx
uses: docker/setup-buildx-action@v2
- name: Login to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USERNAME }}
password: ${{ secrets.DOCKER_TOKEN }}
- name: Login to private repository
uses: docker/login-action@v2
with:
registry: ${{ secrets.PRIVATE_REGISTRY }}
username: registry
password: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# TODO : code scan
# Build image
- name: Build image
uses: docker/build-push-action@v3
with:
context: .
file: src/ui/Dockerfile
platforms: linux/amd64
load: true
#push: true
tags: local/ui:dev
cache-from: type=registry,ref=bunkerity/cache:dev-ui-amd64-cache
cache-to: type=registry,ref=bunkerity/cache:dev-ui-amd64-cache,mode=min
# Check OS vulnerabilities
- name: Check OS vulnerabilities
uses: aquasecurity/trivy-action@master
with:
vuln-type: os
image-ref: local/ui:dev
format: table
exit-code: 1
ignore-unfixed: false
severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL
# trivyignores: .trivyignore
# Containers
build-bw:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: dev
ARCH: linux/amd64
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-sc:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: dev
ARCH: linux/amd64
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-au:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: dev
ARCH: linux/amd64
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-ui:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: dev
ARCH: linux/amd64
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# Python code security
code-security:
@ -207,3 +81,13 @@ jobs:
uses: github/codeql-action/analyze@v2
with:
category: "/language:${{matrix.language}}"
# UI tests
tests-ui:
needs: [code-security, build-bw, build-sc, build-ui]
uses: ./.github/workflows/tests-ui.yml
with:
RELEASE: dev
secrets:
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}

394
.github/workflows/release.yml vendored Normal file
View File

@ -0,0 +1,394 @@
name: Automatic push (RELEASE)
permissions: read-all
on:
push:
branches: [master]
jobs:
# Build BW amd64 + i386 images
build-bw-amd64:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/amd64
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
build-bw-386:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/386
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# Build SC amd64 + i386 images
build-sc-amd64:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/amd64
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
build-sc-386:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/386
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# Build AU amd64 + i386 images
build-au-amd64:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/amd64
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
build-au-386:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/386
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# Build UI amd64 + i386 images
build-ui-amd64:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/amd64
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
build-ui-386:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/386
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# Build arm64 + arm/v7 images
build-bw-arm:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/arm64,linux/arm/v7
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
build-sc-arm:
needs: ["build-bw-arm"]
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/arm64,linux/arm/v7
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
build-au-arm:
needs: ["build-sc-arm"]
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/arm64,linux/arm/v7
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
build-ui-arm:
needs: ["build-au-arm"]
uses: ./.github/workflows/container-build.yml
with:
RELEASE: latest
ARCH: linux/arm64,linux/arm/v7
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
CACHE: false
PUSH: false
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# Linux packages
build-ubuntu:
uses: ./.github/workflows/linux-build.yml
with:
RELEASE: latest
LINUX: ubuntu
PACKAGE: deb
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-debian:
uses: ./.github/workflows/linux-build.yml
with:
RELEASE: latest
LINUX: debian
PACKAGE: deb
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# build-centos:
# uses: ./.github/workflows/linux-build.yml
# with:
# RELEASE: latest
# LINUX: centos
# PACKAGE: rpm
# secrets:
# DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
# DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
# PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-fedora:
uses: ./.github/workflows/linux-build.yml
with:
RELEASE: latest
LINUX: fedora
PACKAGE: rpm
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-rhel:
uses: ./.github/workflows/linux-build.yml
with:
RELEASE: latest
LINUX: rhel
PACKAGE: rpm
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# Wait for all builds and extract VERSION
wait-builds:
needs: [
build-bw-amd64, build-bw-386,
build-sc-amd64, build-sc-386,
build-au-amd64, build-au-386,
build-ui-amd64, build-ui-386,
build-ui-arm,
build-ubuntu,
build-debian,
build-fedora,
build-rhel
]
steps:
- name: Checkout source code
uses: actions/checkout@v3
- name: Get VERSION
id: getversion
run: echo "::set-output name=version::$(cat src/VERSION | tr -d '\n')"
# Push Docker images
push-bunkerweb:
needs: [wait-builds]
uses: ./.github/workflows/push-docker.yml
with:
IMAGE: bunkerity/bunkerweb:latest,bunkerity/bunkerweb:${{ jobs.wait-builds.steps.getversion.outputs.version }}
CACHE_FROM: bunkerweb-latest
DOCKERFILE: src/bw/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
ARM_SSH_KEY: ${{ secrets.ARM_SSH_KEY }}
ARM_SSH_CONFIG: ${{ secrets.ARM_SSH_CONFIG }}
push-scheduler:
needs: [wait-builds]
uses: ./.github/workflows/push-docker.yml
with:
IMAGE: bunkerity/bunkerweb-scheduler:latest,bunkerity/bunkerweb-scheduler:${{ jobs.wait-builds.steps.getversion.outputs.version }}
CACHE_FROM: scheduler-latest
DOCKERFILE: src/scheduler/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
ARM_SSH_KEY: ${{ secrets.ARM_SSH_KEY }}
ARM_SSH_CONFIG: ${{ secrets.ARM_SSH_CONFIG }}
push-autoconf:
needs: [wait-builds]
uses: ./.github/workflows/push-docker.yml
with:
IMAGE: bunkerity/bunkerweb-autoconf:latest,bunkerity/bunkerweb-autoconf:${{ jobs.wait-builds.steps.getversion.outputs.version }}
CACHE_FROM: autoconf-latest
DOCKERFILE: src/autoconf/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
ARM_SSH_KEY: ${{ secrets.ARM_SSH_KEY }}
ARM_SSH_CONFIG: ${{ secrets.ARM_SSH_CONFIG }}
push-ui:
needs: [wait-builds]
uses: ./.github/workflows/push-docker.yml
with:
IMAGE: bunkerity/bunkerweb-ui:latest,bunkerity/bunkerweb-ui:${{ jobs.wait-builds.steps.getversion.outputs.version }}
CACHE_FROM: ui-latest
DOCKERFILE: src/ui/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
ARM_SSH_KEY: ${{ secrets.ARM_SSH_KEY }}
ARM_SSH_CONFIG: ${{ secrets.ARM_SSH_CONFIG }}
# Push Linux packages
push-ubuntu:
needs: [wait-builds]
uses: ./.github/workflows/push-packagecloud.yml
with:
SEPARATOR: _
SUFFIX: amd64
REPO: bunkerweb
LINUX: ubuntu
VERSION: jammy
PACKAGE: deb
BW_VERSION: ${{ jobs.wait-builds.steps.getversion.outputs.version }}
secrets:
PACKAGECLOUD_TOKEN: ${{ secrets.PACKAGECLOUD_TOKEN }}
push-debian:
needs: [wait-builds]
uses: ./.github/workflows/push-packagecloud.yml
with:
SEPARATOR: _
SUFFIX: amd64
REPO: bunkerweb
LINUX: debian
VERSION: bullseye
PACKAGE: deb
BW_VERSION: ${{ jobs.wait-builds.steps.getversion.outputs.version }}
secrets:
PACKAGECLOUD_TOKEN: ${{ secrets.PACKAGECLOUD_TOKEN }}
push-rhel:
needs: [wait-builds]
uses: ./.github/workflows/staging-push-packagecloud.yml
with:
SEPARATOR: "-"
SUFFIX: 1.x86_64
REPO: bunkerweb
LINUX: el
VERSION: 8
PACKAGE: rpm
BW_VERSION: ${{ jobs.wait-builds.steps.getversion.outputs.version }}
secrets:
PACKAGECLOUD_TOKEN: ${{ secrets.PACKAGECLOUD_TOKEN }}
push-fedora:
needs: [wait-builds]
uses: ./.github/workflows/push-packagecloud.yml
with:
SEPARATOR: "-"
SUFFIX: 1.x86_64
REPO: bunkerweb
LINUX: fedora
VERSION: 37
PACKAGE: rpm
BW_VERSION: ${{ jobs.wait-builds.steps.getversion.outputs.version }}
secrets:
PACKAGECLOUD_TOKEN: ${{ secrets.PACKAGECLOUD_TOKEN }}
# Create tag + release + discussion
publish-latest:
needs: [
push-bunkerweb,
push-scheduler,
push-autoconf,
push-ui,
push-ubuntu,
push-debian,
push-rhel,
push-fedora
]
permissions:
contents: write
steps:
- uses: actions/checkout@v3
- uses: rickstaa/action-create-tag@v1
name: Create tag
with:
tag: "v${{ jobs.wait-builds.steps.getversion.outputs.version }}"
message: "v${{ jobs.wait-builds.steps.getversion.outputs.version }}"
- name: Extract changelog
id: getchangelog
run: echo "::set-output name=content::$(awk -v n=2 '/##/{n--}; n > 0' CHANGELOG.md | grep -v '# Changelog' | grep -v '##' | sed '/^$/d')"
- name: Create release
uses: softprops/action-gh-release@v1
with:
body: |
Documentation : https://docs.bunkerweb.io/${{ jobs.wait-builds.steps.getversion.outputs.version }}/
Docker tags :
- `bunkerity/bunkerweb:${{ jobs.wait-builds.steps.getversion.outputs.version }}`
- `bunkerity/bunkerweb-scheduler:${{ jobs.wait-builds.steps.getversion.outputs.version }}`
- `bunkerity/bunkerweb-autoconf:${{ jobs.wait-builds.steps.getversion.outputs.version }}`
- `bunkerity/bunkerweb-ui:${{ jobs.wait-builds.steps.getversion.outputs.version }}`
Linux packages : https://packagecloud.io/app/bunkerity/bunkerweb/search?q=${{ jobs.wait-builds.steps.getversion.outputs.version }}&filter=all&dist=
Changelog :
${{steps.getchangelog.outputs.content}}
draft: false
prerelease: false
name: v${{ jobs.wait-builds.steps.getversion.outputs.version }}
tag_name: v${{ jobs.wait-builds.steps.getversion.outputs.version }}
discussion_category_name: Announcements

144
.github/workflows/staging.yml vendored
View File

@ -8,54 +8,54 @@ on:
jobs:
# Containers
build-bw:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: staging
ARCH: linux/amd64
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-scheduler:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: staging
ARCH: linux/amd64
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-autoconf:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: staging
ARCH: linux/amd64
IMAGE: autoconf
DOCKERFILE: src/autoconf/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-ui:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: staging
ARCH: linux/amd64
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# build-bw:
# uses: ./.github/workflows/container-build.yml
# with:
# RELEASE: staging
# ARCH: linux/amd64
# IMAGE: bunkerweb
# DOCKERFILE: src/bw/Dockerfile
# secrets:
# DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
# DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
# PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# build-scheduler:
# uses: ./.github/workflows/container-build.yml
# with:
# RELEASE: staging
# ARCH: linux/amd64
# IMAGE: scheduler
# DOCKERFILE: src/scheduler/Dockerfile
# secrets:
# DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
# DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
# PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# build-autoconf:
# uses: ./.github/workflows/container-build.yml
# with:
# RELEASE: staging
# ARCH: linux/amd64
# IMAGE: autoconf
# DOCKERFILE: src/autoconf/Dockerfile
# secrets:
# DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
# DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
# PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# build-ui:
# uses: ./.github/workflows/container-build.yml
# with:
# RELEASE: staging
# ARCH: linux/amd64
# IMAGE: ui
# DOCKERFILE: src/ui/Dockerfile
# secrets:
# DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
# DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
# PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
# PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# Linux
build-ubuntu:
@ -146,13 +146,13 @@ jobs:
# TYPE: docker
# secrets:
# CICD_SECRETS: ${{ secrets.CICD_SECRETS }}
create-infra-autoconf:
needs: [code-security, build-bw, build-scheduler, build-autoconf]
uses: ./.github/workflows/staging-create-infra.yml
with:
TYPE: autoconf
secrets:
CICD_SECRETS: ${{ secrets.CICD_SECRETS }}
# create-infra-autoconf:
# needs: [code-security, build-bw, build-scheduler, build-autoconf]
# uses: ./.github/workflows/staging-create-infra.yml
# with:
# TYPE: autoconf
# secrets:
# CICD_SECRETS: ${{ secrets.CICD_SECRETS }}
# create-infra-swarm:
# needs: [code-security, build-bw, build-scheduler, build-autoconf]
# uses: ./.github/workflows/staging-create-infra.yml
@ -190,13 +190,13 @@ jobs:
# TYPE: docker
# RUNS_ON: "['self-hosted', 'bw-docker']"
# secrets: inherit
tests-autoconf:
needs: [create-infra-autoconf]
uses: ./.github/workflows/staging-tests.yml
with:
TYPE: autoconf
RUNS_ON: "['self-hosted', 'bw-autoconf']"
secrets: inherit
# tests-autoconf:
# needs: [create-infra-autoconf]
# uses: ./.github/workflows/staging-tests.yml
# with:
# TYPE: autoconf
# RUNS_ON: "['self-hosted', 'bw-autoconf']"
# secrets: inherit
# tests-swarm:
# needs: [create-infra-swarm]
# uses: ./.github/workflows/staging-tests.yml
@ -220,9 +220,9 @@ jobs:
secrets: inherit
tests-ui:
needs: [code-security, build-ui]
uses: ./.github/workflows/staging-tests-ui.yml
uses: ./.github/workflows/tests-ui.yml
with:
MODE: staging
RELEASE: staging
secrets:
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
@ -236,14 +236,14 @@ jobs:
# TYPE: docker
# secrets:
# CICD_SECRETS: ${{ secrets.CICD_SECRETS }}
delete-infra-autoconf:
if: ${{ always() }}
needs: [tests-autoconf]
uses: ./.github/workflows/staging-delete-infra.yml
with:
TYPE: autoconf
secrets:
CICD_SECRETS: ${{ secrets.CICD_SECRETS }}
# delete-infra-autoconf:
# if: ${{ always() }}
# needs: [tests-autoconf]
# uses: ./.github/workflows/staging-delete-infra.yml
# with:
# TYPE: autoconf
# secrets:
# CICD_SECRETS: ${{ secrets.CICD_SECRETS }}
# delete-infra-swarm:
# if: ${{ always() }}
# needs: [tests-swarm]

12
.github/workflows/staging-tests-ui.yml → .github/workflows/tests-ui.yml vendored
View File

@ -1,9 +1,9 @@
name: Perform staging tests for UI (REUSABLE)
name: Perform tests for UI (REUSABLE)
on:
workflow_call:
inputs:
MODE:
RELEASE:
required: true
type: string
secrets:
@ -25,13 +25,13 @@ jobs:
username: registry
password: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
- name: Pull BW image
run: docker pull ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests:staging && docker tag ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests:staging bunkerweb-tests
run: docker pull ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests:${{ inputs.RELEASE }} && docker tag ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests:${{ inputs.RELEASE }} bunkerweb-tests
- name: Pull Scheduler image
run: docker pull ${{ secrets.PRIVATE_REGISTRY }}/infra/scheduler-tests:staging && docker tag ${{ secrets.PRIVATE_REGISTRY }}/infra/scheduler-tests:staging scheduler-tests
run: docker pull ${{ secrets.PRIVATE_REGISTRY }}/infra/scheduler-tests:${{ inputs.RELEASE }} && docker tag ${{ secrets.PRIVATE_REGISTRY }}/infra/scheduler-tests:${{ inputs.RELEASE }} scheduler-tests
- name: Pull UI image
run: docker pull ${{ secrets.PRIVATE_REGISTRY }}/infra/ui-tests:staging && docker tag ${{ secrets.PRIVATE_REGISTRY }}/infra/ui-tests:staging ui-tests
run: docker pull ${{ secrets.PRIVATE_REGISTRY }}/infra/ui-tests:${{ inputs.RELEASE }} && docker tag ${{ secrets.PRIVATE_REGISTRY }}/infra/ui-tests:${{ inputs.RELEASE }} ui-tests
# Do tests
- name: Run tests
run: ./tests/ui/tests.sh
env:
MODE: ${{ inputs.MODE }}
MODE: ${{ inputs.RELEASE }}

57
.github/workflows/ui.yml vendored Normal file
View File

@ -0,0 +1,57 @@
name: Automatic tests (UI)
permissions: read-all
on:
push:
branches: [ui]
jobs:
# Containers
build-bw:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: ui
ARCH: linux/amd64
IMAGE: bunkerweb
DOCKERFILE: src/bw/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-sc:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: ui
ARCH: linux/amd64
IMAGE: scheduler
DOCKERFILE: src/scheduler/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
build-ui:
uses: ./.github/workflows/container-build.yml
with:
RELEASE: ui
ARCH: linux/amd64
IMAGE: ui
DOCKERFILE: src/ui/Dockerfile
secrets:
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
DOCKER_TOKEN: ${{ secrets.DOCKER_TOKEN }}
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}
# UI tests
tests-ui:
needs: [code-security, build-bw, build-sc, build-ui]
uses: ./.github/workflows/tests-ui.yml
with:
RELEASE: ui
secrets:
PRIVATE_REGISTRY: ${{ secrets.PRIVATE_REGISTRY }}
PRIVATE_REGISTRY_TOKEN: ${{ secrets.PRIVATE_REGISTRY_TOKEN }}

2
docs/about.md
View File

@ -34,7 +34,7 @@ Here is a non-exhaustive list of what you can do :
- Follow us on [LinkedIn](https://www.linkedin.com/company/bunkerity/), [Twitter](https://twitter.com/bunkerity) and [GitHub](https://github.com/bunkerity)
- Report bugs and propose new features using [issues](https://github.com/bunkerity/bunkerweb/issues)
- Contribute to the code using [pull requests](https://github.com/bunkerity/bunkerweb/pulls)
- Write an awesome [plugin](/1.5.0-beta/plugins)
- Write an awesome [plugin](/current_bw_version/plugins)
- Talk about BunkerWeb to your friends/colleagues, on social media, on your blog, ...
## How to report security issue ?

3
docs/assets/extra.js Normal file
View File

@ -0,0 +1,3 @@
window.onload = function set_bw_version() {
document.body.innerHTML = document.body.innerHTML.replaceAll('current_bw_version', '1.5.0-beta');
}

24
docs/concepts.md
View File

@ -10,19 +10,19 @@ The first concept is the integration of BunkerWeb into the target environment. W
The following integrations are officially supported :
- [Docker](/1.5.0-beta/integrations/#docker)
- [Docker autoconf](/1.5.0-beta/integrations/#docker-autoconf)
- [Swarm](/1.5.0-beta/integrations/#swarm)
- [Kubernetes](/1.5.0-beta/integrations/#kubernetes)
- [Linux](/1.5.0-beta/integrations/#linux)
- [Ansible](/1.5.0-beta/integrations/#ansible)
- [Vagrant](/1.5.0-beta/integrations/#vagrant)
- [Docker](/current_bw_version/integrations/#docker)
- [Docker autoconf](/current_bw_version/integrations/#docker-autoconf)
- [Swarm](/current_bw_version/integrations/#swarm)
- [Kubernetes](/current_bw_version/integrations/#kubernetes)
- [Linux](/current_bw_version/integrations/#linux)
- [Ansible](/current_bw_version/integrations/#ansible)
- [Vagrant](/current_bw_version/integrations/#vagrant)
If you think that a new integration should be supported, do not hesitate to open a [new issue](https://github.com/bunkerity/bunkerweb/issues) on the GitHub repository.
!!! info "Going further"
The technical details of all BunkerWeb integrations are available in the [integrations section](/1.5.0-beta/integrations) of the documentation.
The technical details of all BunkerWeb integrations are available in the [integrations section](/current_bw_version/integrations) of the documentation.
## Settings
@ -44,7 +44,7 @@ USE_BROTLI=no
!!! info "Going further"
The complete list of available settings with descriptions and possible values is available in the [settings section](/1.5.0-beta/settings) of the documentation.
The complete list of available settings with descriptions and possible values is available in the [settings section](/current_bw_version/settings) of the documentation.
!!! info "Settings generator tool"
@ -79,11 +79,11 @@ app3.example.com_USE_BAD_BEHAVIOR=no
!!! info "Going further"
You will find concrete examples of multisite mode in the [quickstart guide](/1.5.0-beta/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/examples) directory of the repository.
You will find concrete examples of multisite mode in the [quickstart guide](/current_bw_version/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/examples) directory of the repository.
## Custom configurations
Because meeting all the use cases only using the settings is not an option (even with [external plugins](/1.5.0-beta/plugins)), you can use custom configurations to solve your specific challenges.
Because meeting all the use cases only using the settings is not an option (even with [external plugins](/current_bw_version/plugins)), you can use custom configurations to solve your specific challenges.
Under the hood, BunkerWeb uses the notorious NGINX web server, that's why you can leverage its configuration system for your specific needs. Custom NGINX configurations can be included in different [contexts](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/#contexts) like HTTP or server (all servers and/or specific server block).
@ -91,7 +91,7 @@ Another core component of BunkerWeb is the ModSecurity Web Application Firewall
!!! info "Going further"
You will find concrete examples of custom configurations in the [quickstart guide](/1.5.0-beta/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/examples) directory of the repository.
You will find concrete examples of custom configurations in the [quickstart guide](/current_bw_version/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/examples) directory of the repository.
## Database

6
docs/index.md
View File

@ -9,9 +9,9 @@
BunkerWeb is a next-generation and open-source Web Application Firewall (WAF).
Being a full-featured web server (based on [NGINX](https://nginx.org/) under the hood), it will protect your web services to make them "secure by default". BunkerWeb integrates seamlessly into your existing environments ([Linux](/1.5.0-beta/integrations/#linux), [Docker](/1.5.0-beta/integrations/#docker), [Swarm](/1.5.0-beta/integrations/#swarm), [Kubernetes](/1.5.0-beta/integrations/#kubernetes), …) and is fully configurable (don't panic, there is an [awesome web UI](/1.5.0-beta/web-ui/) if you don't like the CLI) to meet your own use-cases . In other words, cybersecurity is no more a hassle.
Being a full-featured web server (based on [NGINX](https://nginx.org/) under the hood), it will protect your web services to make them "secure by default". BunkerWeb integrates seamlessly into your existing environments ([Linux](/current_bw_version/integrations/#linux), [Docker](/current_bw_version/integrations/#docker), [Swarm](/current_bw_version/integrations/#swarm), [Kubernetes](/current_bw_version/integrations/#kubernetes), …) and is fully configurable (don't panic, there is an [awesome web UI](/current_bw_version/web-ui/) if you don't like the CLI) to meet your own use-cases . In other words, cybersecurity is no more a hassle.
BunkerWeb contains primary [security features](/1.5.0-beta/security-tuning/) as part of the core but can be easily extended with additional ones thanks to a [plugin system](/1.5.0-beta/plugins/).
BunkerWeb contains primary [security features](/current_bw_version/security-tuning/) as part of the core but can be easily extended with additional ones thanks to a [plugin system](/current_bw_version/plugins/).
## Why BunkerWeb ?
@ -35,7 +35,7 @@ A non-exhaustive list of security features :
- **Block known bad IPs** with external blacklists and DNSBL
- And much more ...
Learn more about the core security features in the [security tuning](/1.5.0-beta/security-tuning) section of the documentation.
Learn more about the core security features in the [security tuning](/current_bw_version/security-tuning) section of the documentation.
## Demo

74
docs/integrations.md
View File

@ -12,7 +12,7 @@ Using BunkerWeb as a [Docker](https://www.docker.com/) container is a quick and
We provide ready-to-use prebuilt images for x64, x86 armv8 and armv7 architectures on [Docker Hub](https://hub.docker.com/r/bunkerity/bunkerweb) :
```shell
docker pull bunkerity/bunkerweb:1.5.0-beta
docker pull bunkerity/bunkerweb:current_bw_version
```
Alternatively, you can build the Docker image directly from the [source](https://github.com/bunkerity/bunkerweb) (and get a coffee ☕ because it may take a long time depending on your hardware) :
@ -30,7 +30,7 @@ Docker integration key concepts are :
- **Networks** to expose ports for clients and connect to upstream web services
!!! info "Database backend"
Please note that we assume you are using SQLite as database backend (which is the default for the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) folder of the repostiory for more information.
Please note that we assume you are using SQLite as database backend (which is the default for the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) folder of the repostiory for more information.
### Environment variables
@ -40,7 +40,7 @@ Settings are passed to BunkerWeb using Docker environment variables :
...
services:
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
labels:
- "bunkerweb.INSTANCE"
environment:
@ -52,14 +52,14 @@ services:
Please note that the `bunkerweb.INSTANCE` is mandatory to make sure the scheduler can detect BunkerWeb instance(s).
!!! info "Full list"
For the complete list of environment variables, see the [settings section](/1.5.0-beta/settings) of the documentation.
For the complete list of environment variables, see the [settings section](/current_bw_version/settings) of the documentation.
### Scheduler
The [scheduler](/1.5.0-beta/concepts/#scheduler) is executed in its own container which is also available on Docker Hub :
The [scheduler](/current_bw_version/concepts/#scheduler) is executed in its own container which is also available on Docker Hub :
```shell
docker pull bunkerity/bunkerweb-scheduler:1.5.0-beta
docker pull bunkerity/bunkerweb-scheduler:current_bw_version
```
Alternatively, you can build the Docker image directly from the [source](https://github.com/bunkerity/bunkerweb) (less coffee ☕ needed than BunkerWeb image) :
@ -76,7 +76,7 @@ A volume is needed to store the SQLite database that will be used by the schedul
...
services:
mybunker:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
volumes:
- bw-data:/data
...
@ -133,7 +133,7 @@ You will need to create the Docker API proxy container, mount the socket and set
...
services:
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
env:
- DOCKER_HOST=tcp://bw-docker:2375
...
@ -180,13 +180,13 @@ The scheduler needs to contact the API of BunkerWeb and for obvious security rea
...
services:
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
networks:
- bw-services
- bw-universe
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
networks:
- bw-universe
- bw-docker
@ -224,10 +224,10 @@ The downside of using environment variables is that the container needs to be re
Instead of defining environment variables for the BunkerWeb container, you simply add **labels** to your web applications containers and the **autoconf** will "automagically" take care of the rest.
!!! info "Multisite mode"
The Docker autoconf integration implies the use of **multisite mode**. Please refer to the [multisite section](/1.5.0-beta/concepts/#multisite-mode) of the documentation for more information.
The Docker autoconf integration implies the use of **multisite mode**. Please refer to the [multisite section](/current_bw_version/concepts/#multisite-mode) of the documentation for more information.
!!! info "Database backend"
Please note that we assume you are using MariaDB as database backend (which is defined using the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) folder of the repostiory for more information.
Please note that we assume you are using MariaDB as database backend (which is defined using the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) folder of the repostiory for more information.
Another container, named `bw-autoconf` for example, containing the autoconf service must be added to the stack. Since two services will generate the configuration for BunkerWeb, a "real" database backend (in other words, not SQLite) also needs to be added :
@ -235,7 +235,7 @@ Another container, named `bw-autoconf` for example, containing the autoconf serv
...
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
labels:
- "bunkerweb.INSTANCE"
environment:
@ -247,7 +247,7 @@ services:
- bw-services
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -336,12 +336,12 @@ Like the [Docker autoconf integration](#docker-autoconf), configuration for web
The recommended setup is to schedule the **BunkerWeb service** as a **global service** on all nodes and the **autoconf, scheduler and Docker API proxy services** as **single replicated services**. Please note that the **Docker API proxy service** needs to be scheduled on a manager node unless you configure it to use a remote API (which is not covered in the documentation).
Since we have multiple instances of BunkerWeb running, a shared data store implemented as a [Redis](https://redis.io/) service must be created : the instances will use it to cache and share data. You will find more information about the Redis settings [here](/1.5.0-beta/settings/#redis)
Since we have multiple instances of BunkerWeb running, a shared data store implemented as a [Redis](https://redis.io/) service must be created : the instances will use it to cache and share data. You will find more information about the Redis settings [here](/current_bw_version/settings/#redis)
Using a shared folder or a specific driver for the database volume is left as an exercise for the reader (and depends on your own use-case).
!!! info "Database backend"
Please note that we assume you are using MariaDB as database backend (which is defined using the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) folder of the repostiory for more information. Clustered database backends setup are out-of-the-scope of this documentation.
Please note that we assume you are using MariaDB as database backend (which is defined using the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) folder of the repostiory for more information. Clustered database backends setup are out-of-the-scope of this documentation.
Here is the stack boilerplate that you can deploy using `docker stack deploy` :
@ -350,7 +350,7 @@ version: "3.5"
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- published: 80
target: 8080
@ -380,7 +380,7 @@ services:
- "bunkerweb.INSTANCE"
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:1.5.0-beta
image: bunkerity/bunkerweb-autoconf:current_bw_version
environment:
- SWARM_MODE=yes
- DOCKER_HOST=tcp://bw-docker:2375
@ -411,7 +411,7 @@ services:
- "node.role == manager"
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
environment:
- SWARM_MODE=yes
- DOCKER_HOST=tcp://bw-docker:2375
@ -507,10 +507,10 @@ The autoconf acts as an [Ingress controller](https://kubernetes.io/docs/concepts
The recommended setup is to define **BunkerWeb** as a **[DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)** which will create a pod on all nodes and the **autoconf and scheduler** as **single replicated [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)**.
Since we have multiple instances of BunkerWeb running, a shared data store implemented as a [Redis](https://redis.io/) service must be created : the instances will use it to cache and share data. You will find more information about the Redis settings [here](/1.5.0-beta/settings/#redis)
Since we have multiple instances of BunkerWeb running, a shared data store implemented as a [Redis](https://redis.io/) service must be created : the instances will use it to cache and share data. You will find more information about the Redis settings [here](/current_bw_version/settings/#redis)
!!! info "Database backend"
Please note that we assume you are using MariaDB as database backend (which is defined using the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see yaml files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) folder of the repostiory for more information. Clustered database backends setup are out-of-the-scope of this documentation.
Please note that we assume you are using MariaDB as database backend (which is defined using the `DATABASE_URI` setting). Other backends for this integration are still possible if you want to : see yaml files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) folder of the repostiory for more information. Clustered database backends setup are out-of-the-scope of this documentation.
Please note that both scheduler and autoconf services needs to access the Kubernetes API. The recommended way of doing it is using [RBAC authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
@ -568,7 +568,7 @@ spec:
spec:
containers:
- name: bunkerweb
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
imagePullPolicy: Always
securityContext:
runAsUser: 101
@ -638,7 +638,7 @@ spec:
serviceAccountName: sa-bunkerweb
containers:
- name: bunkerweb-controller
image: bunkerity/bunkerweb-autoconf:1.5.0-beta
image: bunkerity/bunkerweb-autoconf:current_bw_version
imagePullPolicy: Always
env:
- name: KUBERNETES_MODE
@ -665,7 +665,7 @@ spec:
serviceAccountName: sa-bunkerweb
containers:
- name: bunkerweb-scheduler
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
imagePullPolicy: Always
env:
- name: KUBERNETES_MODE
@ -780,7 +780,7 @@ spec:
storage: 5Gi
```
Once the BunkerWeb Kubernetes stack is set up and running (see autoconf logs for more information), you will be able to deploy web applications in the cluster and declare your Ingress resource. Please note that [settings](/1.5.0-beta/settings) need to be set as annotations for the Ingress resource with the special value **bunkerweb.io** for the domain part :
Once the BunkerWeb Kubernetes stack is set up and running (see autoconf logs for more information), you will be able to deploy web applications in the cluster and declare your Ingress resource. Please note that [settings](/current_bw_version/settings) need to be set as annotations for the Ingress resource with the special value **bunkerweb.io** for the domain part :
```yaml
apiVersion: networking.k8s.io/v1
@ -843,12 +843,12 @@ Repositories of Linux packages for BunkerWeb are available on [PackageCloud](htt
sudo apt install -y nginx=1.24.0-1~$(lsb_release -cs)
```
And finally install BunkerWeb 1.5.0-beta :
And finally install BunkerWeb current_bw_version :
```shell
curl -s https://packagecloud.io/install/repositories/bunkerity/bunkerweb/script.deb.sh | sudo bash && \
sudo apt update && \
sudo apt install -y bunkerweb=1.5.0-beta
sudo apt install -y bunkerweb=current_bw_version
```
To prevent upgrading NGINX and/or BunkerWeb packages when executing `apt upgrade`, you can use the following command :
@ -877,12 +877,12 @@ Repositories of Linux packages for BunkerWeb are available on [PackageCloud](htt
sudo apt install -y nginx=1.24.0-1~jammy
```
And finally install BunkerWeb 1.5.0-beta :
And finally install BunkerWeb current_bw_version :
```shell
curl -s https://packagecloud.io/install/repositories/bunkerity/bunkerweb/script.deb.sh | sudo bash && \
sudo apt update && \
sudo apt install -y bunkerweb=1.5.0-beta
sudo apt install -y bunkerweb=current_bw_version
```
To prevent upgrading NGINX and/or BunkerWeb packages when executing `apt upgrade`, you can use the following command :
@ -899,14 +899,14 @@ Repositories of Linux packages for BunkerWeb are available on [PackageCloud](htt
sudo dnf install -y nginx-1.24.0
```
And finally install BunkerWeb 1.5.0-beta :
And finally install BunkerWeb current_bw_version :
```shell
curl -s https://packagecloud.io/install/repositories/bunkerity/bunkerweb/script.rpm.sh | \
sed 's/yum install -y pygpgme --disablerepo='\''bunkerity_bunkerweb'\''/yum install -y python-gnupg/g' | \
sed 's/pypgpme_check=`rpm -qa | grep -qw pygpgme`/python-gnupg_check=`rpm -qa | grep -qw python-gnupg`/g' | sudo bash && \
sudo dnf makecache && \
sudo dnf install -y bunkerweb-1.5.0-beta
sudo dnf install -y bunkerweb-current_bw_version
```
To prevent upgrading NGINX and/or BunkerWeb packages when executing `dnf upgrade`, you can use the following command :
@ -943,13 +943,13 @@ Repositories of Linux packages for BunkerWeb are available on [PackageCloud](htt
```shell
sudo dnf install nginx-1.24.0
```
And finally install BunkerWeb 1.5.0-beta :
And finally install BunkerWeb current_bw_version :
```shell
dnf install -y epel-release && \
curl -s https://packagecloud.io/install/repositories/bunkerity/bunkerweb/script.rpm.sh | sudo bash && \
sudo dnf check-update && \
sudo dnf install -y bunkerweb-1.5.0-beta
sudo dnf install -y bunkerweb-current_bw_version
```
To prevent upgrading NGINX and/or BunkerWeb packages when executing `dnf upgrade`, you can use the following command :
@ -978,12 +978,12 @@ Repositories of Linux packages for BunkerWeb are available on [PackageCloud](htt
sudo dnf install nginx-1.24.0
```
And finally install BunkerWeb 1.5.0-beta :
And finally install BunkerWeb current_bw_version :
```shell
dnf install -y epel-release && \
curl -s https://packagecloud.io/install/repositories/bunkerity/bunkerweb/script.rpm.sh | sudo bash && \
sudo dnf check-update && \
sudo dnf install -y bunkerweb-1.5.0-beta
sudo dnf install -y bunkerweb-current_bw_version
```
To prevent upgrading NGINX and/or BunkerWeb packages when executing `dnf upgrade`, you can use the following command :
@ -1007,7 +1007,7 @@ Repositories of Linux packages for BunkerWeb are available on [PackageCloud](htt
https://github.com/bunkerity/bunkerweb.git /tmp/bunkerweb
```
BunkerWeb needs some dependencies to be compiled and installed to `/usr/share/bunkerweb/deps`, the easiest way to do it is by executing the [install.sh helper script](https://github.com/bunkerity/bunkerweb/blob/1.5.0-beta/deps/install.sh) (please note that you will need to install additional packages which is not covered in this procedure and depends on your own system) :
BunkerWeb needs some dependencies to be compiled and installed to `/usr/share/bunkerweb/deps`, the easiest way to do it is by executing the [install.sh helper script](https://github.com/bunkerity/bunkerweb/blob/current_bw_version/deps/install.sh) (please note that you will need to install additional packages which is not covered in this procedure and depends on your own system) :
```
mkdir /usr/share/bunkerweb/deps && \
/tmp/bunkerweb/src/deps/install.sh
@ -1123,7 +1123,7 @@ Configuration of BunkerWeb is done by using specific role variables :
| Name | Type | Description | Default value |
|:-----:|:-----:|--------------|----------------|
| `bunkerweb_version` | string | Version of BunkerWeb to install. | `1.5.0-beta` |
| `bunkerweb_version` | string | Version of BunkerWeb to install. | `current_bw_version` |
| `nginx_version` | string | Version of NGINX to install. | `1.24.0` |
| `freeze_versions` | boolean | Prevent upgrade of BunkerWeb and NGINX when performing packages upgrades. | `true` |
| `variables_env` | string | Path of the variables.env file to configure BunkerWeb. | `files/variables.env` |

10
docs/migrating.md
View File

@ -2,7 +2,7 @@
!!! warning "Read this if you were a 1.4.X user"
A lot of things changed since the 1.4.X releases. Container-based integrations stacks contain more services but, trust us, fundamental principles of BunkerWeb are still there.
A lot of things changed since the 1.4.X releases. Container-based integrations stacks contain more services but, trust us, fundamental principles of BunkerWeb are still there. You will find ready to use boilerplates for various integrations in the [misc/integrations](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) folder of the repository.
## Scheduler
@ -10,7 +10,7 @@ Back to the 1.4.X releases, jobs (like Let's Encrypt certificate generation/rene
Called **Scheduler**, this service also generates the final configuration used by BunkerWeb and acts as an intermediary between autoconf and BunkerWeb. In other words, the scheduler is the **brain of the BunkerWeb 1.5.X stack**.
You will find more information about the scheduler [here](/1.5.0-beta/concepts/#scheduler).
You will find more information about the scheduler [here](/current_bw_version/concepts/#scheduler).
## Database
@ -24,7 +24,7 @@ Using a real database offers many advantages :
Please note that we actually support, **SQLite**, **MySQL**, **MariaDB** and **PostgreSQL** as backends.
You will find more information about the database [here](/1.5.0-beta/concepts/#database).
You will find more information about the database [here](/current_bw_version/concepts/#database).
## Redis
@ -34,8 +34,8 @@ Security is not the only reason to have a shared data store for clustered integr
We actually support **Redis** as a backend for the shared data store.
See the list of [redis settings](/1.5.0-beta/settings/#redis) and the corresponding documentation of your integration for more information.
See the list of [redis settings](/current_bw_version/settings/#redis) and the corresponding documentation of your integration for more information.
## Default values and new settings
The default value of some settings have changed and we have added many other settings, we recommend you read the [security tuning](/1.5.0-beta/security-tuning) and [settings](/1.5.0-beta/settings) sections of the documentation.
The default value of some settings have changed and we have added many other settings, we recommend you read the [security tuning](/current_bw_version/security-tuning) and [settings](/current_bw_version/settings) sections of the documentation.

34
docs/plugins.md
View File

@ -28,7 +28,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Docker"
When using the [Docker integration](/integrations/#docker), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
When using the [Docker integration](current_bw_version/integrations/#docker), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
The first thing to do is to create the plugins folder :
@ -56,7 +56,7 @@ The first step is to install the plugin by putting the plugin files inside the c
services:
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
volumes:
- ./bw-data:/data
...
@ -64,7 +64,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Docker autoconf"
When using the [Docker autoconf integration](/integrations/#docker-autoconf), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
When using the [Docker autoconf integration](current_bw_version/integrations/#docker-autoconf), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
The first thing to do is to create the plugins folder :
@ -93,7 +93,7 @@ The first step is to install the plugin by putting the plugin files inside the c
services:
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
volumes:
- ./bw-data:/data
...
@ -101,7 +101,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Swarm"
When using the [Swarm integration](/integrations/#swarm), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
When using the [Swarm integration](current_bw_version/integrations/#swarm), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
!!! info "Swarm volume"
Configuring a Swarm volume that will persist when the scheduler service is running on different nodes is not covered is in this documentation. We will assume that you have a shared folder mounted on `/shared` accross all nodes.
@ -132,7 +132,7 @@ The first step is to install the plugin by putting the plugin files inside the c
services:
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
volumes:
- /shared/bw-plugins:/data/plugins
...
@ -140,7 +140,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Kubernetes"
When using the [Kubernetes integration](/integrations/#kubernetes), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
When using the [Kubernetes integration](current_bw_version/integrations/#kubernetes), plugins must be written to the volume mounted on `/data/plugins` into the scheduler container.
The fist thing to do is to declare a [PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) that will contain our plugins data :
@ -179,7 +179,7 @@ The first step is to install the plugin by putting the plugin files inside the c
serviceAccountName: sa-bunkerweb
containers:
- name: bunkerweb-scheduler
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
imagePullPolicy: Always
env:
- name: KUBERNETES_MODE
@ -205,7 +205,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Linux"
When using the [Linux integration](/integrations/#linux), plugins must be written to the `/etc/bunkerweb/plugins` folder :
When using the [Linux integration](current_bw_version/integrations/#linux), plugins must be written to the `/etc/bunkerweb/plugins` folder :
```shell
git clone https://github.com/bunkerity/bunkerweb-plugins && \
@ -215,7 +215,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Ansible"
When using the [Ansible integration](/integrations/#ansible), you can use the `plugins` variable to set a local folder containing your plugins that will be copied to your BunkerWeb instances.
When using the [Ansible integration](current_bw_version/integrations/#ansible), you can use the `plugins` variable to set a local folder containing your plugins that will be copied to your BunkerWeb instances.
Let's assume that you have plugins inside the `bunkerweb-plugins` folder :
@ -249,7 +249,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Vagrant"
When using the [Vagrant integration](/integrations/#vagrant), plugins must be written to the `/etc/bunkerweb/plugins` folder (you will need to do a `vagrant ssh` first) :
When using the [Vagrant integration](current_bw_version/integrations/#vagrant), plugins must be written to the `/etc/bunkerweb/plugins` folder (you will need to do a `vagrant ssh` first) :
```shell
git clone https://github.com/bunkerity/bunkerweb-plugins && \
@ -260,7 +260,7 @@ The first step is to install the plugin by putting the plugin files inside the c
!!! tip "Existing plugins"
If the documentation is not enough, you can have a look at the existing source code of [official plugins](https://github.com/bunkerity/bunkerweb-plugins) and the [core plugins](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/src/common/core) (already included in BunkerWeb but they are plugins, technically speaking).
If the documentation is not enough, you can have a look at the existing source code of [official plugins](https://github.com/bunkerity/bunkerweb-plugins) and the [core plugins](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/src/common/core) (already included in BunkerWeb but they are plugins, technically speaking).
The first step is to create a folder that will contain the plugin :
@ -339,7 +339,7 @@ Each job has the following fields :
### Configurations
You can add custom NGINX configurations by adding a folder named **confs** with content similar to the [custom configurations](/quickstart-guide/#custom-configurations). Each subfolder inside the **confs** will contain [jinja2](https://jinja.palletsprojects.com) templates that will be generated and loaded at the corresponding context (`http`, `server-http`, `default-server-http`, `stream` and `server-stream`).
You can add custom NGINX configurations by adding a folder named **confs** with content similar to the [custom configurations](/current_bw_version/quickstart-guide/#custom-configurations). Each subfolder inside the **confs** will contain [jinja2](https://jinja.palletsprojects.com) templates that will be generated and loaded at the corresponding context (`http`, `server-http`, `default-server-http`, `stream` and `server-stream`).
Here is an example for a configuration template file inside the **confs/server-http** folder named **example.conf** :
@ -426,7 +426,7 @@ The declared functions are automatically called during specific contexts. Here a
#### Libraries
All directives from [NGINX LUA module](https://github.com/openresty/lua-nginx-module) and are available and [NGINX stream LUA module](https://github.com/openresty/stream-lua-nginx-module). On top of that, you can use the LUA libraries included within BunkerWeb : see [this script](https://github.com/bunkerity/bunkerweb/blob/1.5.0-beta/src/deps/clone.sh) for the complete list.
All directives from [NGINX LUA module](https://github.com/openresty/lua-nginx-module) and are available and [NGINX stream LUA module](https://github.com/openresty/stream-lua-nginx-module). On top of that, you can use the LUA libraries included within BunkerWeb : see [this script](https://github.com/bunkerity/bunkerweb/blob/current_bw_version/src/deps/clone.sh) for the complete list.
If you need additional libraries, you can put them in the root folder of the plugin and access them by prefixing them with your plugin ID. Here is an example file named **mylibrary.lua** :
@ -507,7 +507,7 @@ end
!!! tip "More examples"
If you want to see the full list of available functions, you can have a look at the files present in the [lua directory](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/src/bw/lua/bunkerweb) of the repository.
If you want to see the full list of available functions, you can have a look at the files present in the [lua directory](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/src/bw/lua/bunkerweb) of the repository.
### Jobs
@ -515,7 +515,7 @@ BunkerWeb uses an internal job scheduler for periodic tasks like renewing certif
### Plugin page
Plugin pages are used to display information about your plugin and interact with the user inside the plugins section of the [web UI](/web-ui).
Plugin pages are used to display information about your plugin and interact with the user inside the plugins section of the [web UI](/current_bw_version/web-ui).
Everything related to the web UI is located inside a subfolder named **ui** at the root directory of your plugin. A template file named **template.html** and located inside the **ui** subfolder contains the client code and logic to display your page. Another file named **actions.py** and also located inside the **ui** subfolder contains code that will be executed when the user is interacting with your page (filling a form for example).
@ -554,4 +554,4 @@ def myplugin() :
!!! info "Python libraries"
You can use Python libraries that are already available like :
`Flask`, `Flask-Login`, `Flask-WTF`, `beautifulsoup4`, `docker`, `Jinja2`, `python-magic` and `requests`. To see the full list, you can have a look at the Web UI [requirements.txt](https://github.com/bunkerity/bunkerweb/blob/1.5.0-beta/src/ui/requirements.txt). If you need external libraries, you can install them inside the **ui** folder of your plugin and then use the classical **import** directive.
`Flask`, `Flask-Login`, `Flask-WTF`, `beautifulsoup4`, `docker`, `Jinja2`, `python-magic` and `requests`. To see the full list, you can have a look at the Web UI [requirements.txt](https://github.com/bunkerity/bunkerweb/blob/current_bw_version/src/ui/requirements.txt). If you need external libraries, you can install them inside the **ui** folder of your plugin and then use the classical **import** directive.

128
docs/quickstart-guide.md
View File

@ -1,10 +1,10 @@
# Quickstart guide
!!! info "Prerequisites"
We assume that you're already familiar with the [core concepts](/1.5.0-beta/concepts) and you have followed the [integrations instructions](/1.5.0-beta/integrations) for your environment.
We assume that you're already familiar with the [core concepts](/current_bw_version/concepts) and you have followed the [integrations instructions](/current_bw_version/integrations) for your environment.
!!! tip "Going further"
To demonstrate the use of BunkerWeb, we will deploy a dummy "Hello World" web application as an example. See the [examples folder](https://github.com/bunkerity/bunkerweb/tree/v1.5.0-beta/examples) of the repository to get real-world examples.
To demonstrate the use of BunkerWeb, we will deploy a dummy "Hello World" web application as an example. See the [examples folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/examples) of the repository to get real-world examples.
## Protect HTTP applications
@ -16,7 +16,7 @@ The following settings can be used :
- `REVERSE_PROXY_URL` : the public path prefix
- `REVERSE_PROXY_HOST` : (internal) address of the proxied web application
You will find more settings about reverse proxy in the [settings section](/1.5.0-beta/settings/#reverse-proxy) of the documentation.
You will find more settings about reverse proxy in the [settings section](/current_bw_version/settings/#reverse-proxy) of the documentation.
### Single application
@ -35,7 +35,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
- bw-services
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- 80:8080
- 443:8443
@ -52,7 +52,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -92,7 +92,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Docker autoconf"
We will assume that you already have the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf) stack running on your machine and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
We will assume that you already have the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf) stack running on your machine and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
```yaml
version: '3.5'
@ -118,7 +118,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Swarm"
We will assume that you already have the [Swarm integration](/1.5.0-beta/integrations/#swarm) stack running on your cluster and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
We will assume that you already have the [Swarm integration](/current_bw_version/integrations/#swarm) stack running on your cluster and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
```yaml
version: "3"
@ -148,7 +148,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Kubernetes"
We will assume that you already have the [Kubernetes integration](/1.5.0-beta/integrations/#kubernetes) stack running on your cluster.
We will assume that you already have the [Kubernetes integration](/current_bw_version/integrations/#kubernetes) stack running on your cluster.
Let's assume that you have a typical Deployment with a Service to access the web application from within the cluster :
@ -213,7 +213,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Linux"
We will assume that you already have the [Linux integration](/1.5.0-beta/integrations/#linux) stack running on your machine.
We will assume that you already have the [Linux integration](/current_bw_version/integrations/#linux) stack running on your machine.
The following command will run a basic HTTP server on the port 8000 and deliver the files in the current directory :
@ -299,7 +299,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Vagrant"
We will assume that you already have the [Vagrant integration](/1.5.0-beta/integrations/#vagrant) stack running on your machine.
We will assume that you already have the [Vagrant integration](/current_bw_version/integrations/#vagrant) stack running on your machine.
The following command will run a basic HTTP server on the port 8000 and deliver the files in the current directory :
@ -385,7 +385,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
- bw-services
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- 80:8080
- 443:8443
@ -405,7 +405,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -444,7 +444,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Docker autoconf"
We will assume that you already have the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf) stack running on your machine and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
We will assume that you already have the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf) stack running on your machine and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
```yaml
version: '3.5'
@ -494,7 +494,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Swarm"
We will assume that you already have the [Swarm integration](/1.5.0-beta/integrations/#swarm) stack running on your cluster and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
We will assume that you already have the [Swarm integration](/current_bw_version/integrations/#swarm) stack running on your cluster and connected to a network called `bw-services` so you can connect your existing application and configure BunkerWeb with labels :
```yaml
version: "3"
@ -556,7 +556,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Kubernetes"
We will assume that you already have the [Kubernetes integration](/1.5.0-beta/integrations/#kubernetes) stack running on your cluster.
We will assume that you already have the [Kubernetes integration](/current_bw_version/integrations/#kubernetes) stack running on your cluster.
Let's assume that you have typical Deployments with a Service to access the web applications from within the cluster :
@ -642,7 +642,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Linux"
We will assume that you already have the [Linux integration](/1.5.0-beta/integrations/#linux) stack running on your machine.
We will assume that you already have the [Linux integration](/current_bw_version/integrations/#linux) stack running on your machine.
The following command will run a basic HTTP server on the port 8001 and deliver the files in the current directory (repeat it and change the port if you want to test BunkerWeb) :
@ -734,7 +734,7 @@ You will find more settings about reverse proxy in the [settings section](/1.5.0
=== "Vagrant"
We will assume that you already have the [Vagrant integration](/1.5.0-beta/integrations/#vagrant) stack running on your machine.
We will assume that you already have the [Vagrant integration](/current_bw_version/integrations/#vagrant) stack running on your machine.
First of all, connect to your vagrant machine :
@ -797,7 +797,7 @@ The following settings can be used :
- `REAL_IP_FROM` : list of trusted IP/network address allowed to send us the "real IP"
- `REAL_IP_HEADER` : the HTTP header containing the real IP or special value `proxy_protocol` when using PROXY protocol
You will find more settings about real IP in the [settings section](/1.5.0-beta/settings/#real-ip) of the documentation.
You will find more settings about real IP in the [settings section](/current_bw_version/settings/#real-ip) of the documentation.
### HTTP header
@ -820,7 +820,7 @@ REAL_IP_HEADER=X-Forwarded-For
```yaml
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
...
environment:
- USE_REAL_IP=yes
@ -831,11 +831,11 @@ REAL_IP_HEADER=X-Forwarded-For
=== "Docker autoconf"
Before running the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
Before running the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
```yaml
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
...
environment:
- USE_REAL_IP=yes
@ -846,11 +846,11 @@ REAL_IP_HEADER=X-Forwarded-For
=== "Swarm"
Before running the [Swarm integration](/1.5.0-beta/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
Before running the [Swarm integration](/current_bw_version/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
```yaml
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
...
environment:
- USE_REAL_IP=yes
@ -970,7 +970,7 @@ REAL_IP_HEADER=proxy_protocol
```yaml
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
...
environment:
- USE_REAL_IP=yes
@ -982,11 +982,11 @@ REAL_IP_HEADER=proxy_protocol
=== "Docker autoconf"
Before running the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
Before running the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
```yaml
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
...
environment:
- USE_REAL_IP=yes
@ -998,11 +998,11 @@ REAL_IP_HEADER=proxy_protocol
=== "Swarm"
Before running the [Swarm integration](/1.5.0-beta/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
Before running the [Swarm integration](/current_bw_version/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
```yaml
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
...
environment:
- USE_REAL_IP=yes
@ -1113,7 +1113,7 @@ REAL_IP_HEADER=proxy_protocol
BunkerWeb can also act as **generic UDP/TCP reverse proxy** : you can protect any network-based applications working at least on layer 4 of the OSI model. Behind the hood, it leverages the [stream module](https://nginx.org/en/docs/stream/ngx_stream_core_module.html) of NGINX instead of using the "classical" http one.
Please note that not all settings and security features are available when using the stream module. You will find more info about that in the [security tuning](/1.5.0-beta/security-tuning/) and [settings](/1.5.0-beta/settings/) sections of the documentation.
Please note that not all settings and security features are available when using the stream module. You will find more info about that in the [security tuning](/current_bw_version/security-tuning/) and [settings](/current_bw_version/settings/) sections of the documentation.
Configuration for a basic reverse proxy is very similar to the HTTP one because it uses the same `USE_REVERSE_PROXY=yes` and `REVERSE_PROXY_HOST=myapp:4242` settings. Even the settings used when BunkerWeb is [behind a Load Balancer](#behind-load-balancer-or-reverse-proxy) are the same (but for obvious reasons, only **PROXY protocol** is supported).
@ -1124,7 +1124,7 @@ On top of that, the following specific settings are used :
- `LISTEN_STREAM_PORT_SSL=4343` : the listening "ssl/tls" port that BunkerWeb will listen on
- `USE_UDP=no` : listen for and forward UDP packets instead of TCP
For complete list of settings regarding `stream` mode, please refer to the [settings](/1.5.0-beta/settings/) section of the documentation.
For complete list of settings regarding `stream` mode, please refer to the [settings](/current_bw_version/settings/) section of the documentation.
=== "Docker"
@ -1148,7 +1148,7 @@ For complete list of settings regarding `stream` mode, please refer to the [sett
- bw-services
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- 80:8080 # Keep it if you want to use Let's Encrypt automation
- 10000:10000 # app1
@ -1170,7 +1170,7 @@ For complete list of settings regarding `stream` mode, please refer to the [sett
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -1210,7 +1210,7 @@ For complete list of settings regarding `stream` mode, please refer to the [sett
=== "Docker autoconf"
Before running the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf) stack on your machine, you will need to edit the ports :
Before running the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf) stack on your machine, you will need to edit the ports :
```yaml
version: "3.5"
@ -1218,7 +1218,7 @@ For complete list of settings regarding `stream` mode, please refer to the [sett
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- 80:8080 # Keep it if you want to use Let's Encrypt automation
- 10000:10000 # app1
@ -1269,14 +1269,14 @@ For complete list of settings regarding `stream` mode, please refer to the [sett
=== "Swarm"
Before running the [Swarm integration](/1.5.0-beta/integrations/#swarm) stack on your machine, you will need to edit the ports :
Before running the [Swarm integration](/current_bw_version/integrations/#swarm) stack on your machine, you will need to edit the ports :
```yaml
version: "3.5"
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
# Keep it if you want to use Let's Encrypt automation
- published: 80
@ -1343,7 +1343,7 @@ For complete list of settings regarding `stream` mode, please refer to the [sett
=== "Kubernetes"
Protection TCP/UDP applications using the `stream` feature is not yet supported when using the [Kubernetes integration](/1.5.0-beta/integrations/#kubernetes).
Protection TCP/UDP applications using the `stream` feature is not yet supported when using the [Kubernetes integration](/current_bw_version/integrations/#kubernetes).
=== "Linux"
@ -1426,7 +1426,7 @@ For complete list of settings regarding `stream` mode, please refer to the [sett
## Custom configurations
Because BunkerWeb is based on the NGINX web server, you can add custom NGINX configurations in different NGINX contexts. You can also apply custom configurations for the ModSecurity WAF which is a core component of BunkerWeb (more info [here](/1.5.0-beta/security-tuning/#modsecurity)). Here is the list of custom configurations types :
Because BunkerWeb is based on the NGINX web server, you can add custom NGINX configurations in different NGINX contexts. You can also apply custom configurations for the ModSecurity WAF which is a core component of BunkerWeb (more info [here](/current_bw_version/security-tuning/#modsecurity)). Here is the list of custom configurations types :
- **http** : http level of NGINX
- **server-http** : http/server level of NGINX
@ -1444,7 +1444,7 @@ Some integrations offer a more convenient way of applying configurations such as
=== "Docker"
When using the [Docker integration](/1.5.0-beta/integrations/#docker), you have two choices for the addition of custom configurations :
When using the [Docker integration](/current_bw_version/integrations/#docker), you have two choices for the addition of custom configurations :
- Using specific settings `*_CUSTOM_CONF_*` as environment variables (recommended)
- Writing .conf files to the volume mounted on /data of the scheduler
@ -1462,7 +1462,7 @@ Some integrations offer a more convenient way of applying configurations such as
```yaml
...
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
environment:
- |
CUSTOM_CONF_SERVER_HTTP_hello-world=
@ -1505,7 +1505,7 @@ Some integrations offer a more convenient way of applying configurations such as
```yaml
mybunker:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
volumes:
- ./bw-data:/data
...
@ -1513,7 +1513,7 @@ Some integrations offer a more convenient way of applying configurations such as
=== "Docker autoconf"
When using the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf), you have two choices for adding custom configurations :
When using the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf), you have two choices for adding custom configurations :
- Using specific settings `*_CUSTOM_CONF_*` as labels (easiest)
- Writing .conf files to the volume mounted on /data of the scheduler
@ -1574,7 +1574,7 @@ Some integrations offer a more convenient way of applying configurations such as
```yaml
myautoconf:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
volumes:
- ./bw-data:/data
...
@ -1582,7 +1582,7 @@ Some integrations offer a more convenient way of applying configurations such as
=== "Swarm"
When using the [Swarm integration](/1.5.0-beta/integrations/#swarm), custom configurations are managed using [Docker Configs](https://docs.docker.com/engine/swarm/configs/).
When using the [Swarm integration](/current_bw_version/integrations/#swarm), custom configurations are managed using [Docker Configs](https://docs.docker.com/engine/swarm/configs/).
To keep it simple, you don't even need to attach the Config to a service : the autoconf service is listening for Config events and will update the custom configurations when needed.
@ -1606,7 +1606,7 @@ Some integrations offer a more convenient way of applying configurations such as
=== "Kubernetes"
When using the [Kubernetes integration](/1.5.0-beta/integrations/#kubernetes), custom configurations are managed using [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/).
When using the [Kubernetes integration](/current_bw_version/integrations/#kubernetes), custom configurations are managed using [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/).
To keep it simple, you don't even need to use the ConfigMap with a Pod (e.g. as environment variable or volume) : the autoconf Pod is listening for ConfigMap events and will update the custom configurations when needed.
@ -1636,7 +1636,7 @@ Some integrations offer a more convenient way of applying configurations such as
=== "Linux"
When using the [Linux integration](/1.5.0-beta/integrations/#linux), custom configurations must be written to the /etc/bunkerweb/configs folder.
When using the [Linux integration](/current_bw_version/integrations/#linux), custom configurations must be written to the /etc/bunkerweb/configs folder.
Here is an example for server-http/hello-world.conf :
@ -1701,7 +1701,7 @@ Some integrations offer a more convenient way of applying configurations such as
=== "Vagrant"
When using the [Vagrant integration](/1.5.0-beta/integrations/#vagrant), custom configurations must be written to the `/etc/bunkerweb/configs` folder.
When using the [Vagrant integration](/current_bw_version/integrations/#vagrant), custom configurations must be written to the `/etc/bunkerweb/configs` folder.
Here is an example for server-http/hello-world.conf :
@ -1750,13 +1750,13 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
=== "Docker"
When using the [Docker integration](/1.5.0-beta/integrations/#docker), to support PHP applications, you will need to :
When using the [Docker integration](/current_bw_version/integrations/#docker), to support PHP applications, you will need to :
- Mount your PHP files into the `/var/www/html` folder of BunkerWeb
- Set up a PHP-FPM container for your application and mount the folder containing PHP files
- Use the specific settings `REMOTE_PHP` and `REMOTE_PHP_PATH` as environment variables when starting BunkerWeb
If you enable the [multisite mode](/1.5.0-beta/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
If you enable the [multisite mode](/current_bw_version/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
```
www
@ -1807,7 +1807,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
- bw-services
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
volumes:
- ./www:/var/www/html
ports:
@ -1830,7 +1830,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -1870,15 +1870,15 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
=== "Docker autoconf"
!!! info "Multisite mode enabled"
The [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf) integration implies the use of multisite mode : protecting one PHP application is the same as protecting multiple ones.
The [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf) integration implies the use of multisite mode : protecting one PHP application is the same as protecting multiple ones.
When using the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf), to support PHP applications, you will need to :
When using the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf), to support PHP applications, you will need to :
- Mount your PHP files into the `/var/www/html` folder of BunkerWeb
- Set up a PHP-FPM containers for your applications and mount the folder containing PHP apps
- Use the specific settings `REMOTE_PHP` and `REMOTE_PHP_PATH` as labels for your PHP-FPM container
Since the Docker autoconf implies using the [multisite mode](/1.5.0-beta/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
Since the Docker autoconf implies using the [multisite mode](/current_bw_version/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
```
www
@ -1907,7 +1907,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
volumes:
- ./www:/var/www/html
labels:
@ -1921,7 +1921,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -2022,18 +2022,18 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
=== "Swarm"
!!! info "Multisite mode enabled"
The [Swarm integration](/1.5.0-beta/integrations/#docker-autoconf) integration implies the use of multisite mode : protecting one PHP application is the same as protecting multiple ones.
The [Swarm integration](/current_bw_version/integrations/#docker-autoconf) integration implies the use of multisite mode : protecting one PHP application is the same as protecting multiple ones.
!!! info "Shared volume"
Using PHP with the Docker Swarm integration needs a shared volume between all BunkerWeb and PHP-FPM instances which is not covered in this documentation.
When using the [Docker autoconf integration](/1.5.0-beta/integrations/#docker-autoconf), to support PHP applications, you will need to :
When using the [Docker autoconf integration](/current_bw_version/integrations/#docker-autoconf), to support PHP applications, you will need to :
- Mount your PHP files into the `/var/www/html` folder of BunkerWeb
- Set up a PHP-FPM containers for your applications and mount the folder containing PHP apps
- Use the specific settings `REMOTE_PHP` and `REMOTE_PHP_PATH` as labels for your PHP-FPM container
Since the Swarm integration implies using the [multisite mode](/1.5.0-beta/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
Since the Swarm integration implies using the [multisite mode](/current_bw_version/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
```
www
@ -2064,7 +2064,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
volumes:
- /shared/www:/var/www/html
...
@ -2139,7 +2139,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
=== "Linux"
We will assume that you already have the [Linux integration](/1.5.0-beta/integrations/#linux) stack running on your machine.
We will assume that you already have the [Linux integration](/current_bw_version/integrations/#linux) stack running on your machine.
By default, BunkerWeb will search for web files inside the `/var/www/html` folder. You can use it to store your PHP applications. Please note that you will need to configure your PHP-FPM service to get or set the user/group of the running processes and the UNIX socket file used to communicate with BunkerWeb.
@ -2163,7 +2163,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
systemctl restart php-fpm
```
If you enable the [multisite mode](/1.5.0-beta/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
If you enable the [multisite mode](/current_bw_version/concepts/#integration), you will need to create separate directories for each of your applications. Each subdirectory should be named using the first value of `SERVER_NAME`. Here is a dummy example :
```
/var/www/html
@ -2224,7 +2224,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
!!! info "Linux"
Please follow the instruction for Linux integration to create a local `www` folder (permissions are not needed, Ansible will do it for you).
We will assume that you already have the [Ansible integration](/1.5.0-beta/integrations/#ansible) setup on your machine.
We will assume that you already have the [Ansible integration](/current_bw_version/integrations/#ansible) setup on your machine.
Content of the `my_variables.env` configuration file :
@ -2273,7 +2273,7 @@ BunkerWeb supports PHP using external or remote [PHP-FPM](https://www.php.net/ma
!!! info "Linux"
Please follow the instruction for Linux integration to create the `/var/www/html` folder.
We will assume that you already have the [Vagrant integration](/1.5.0-beta/integrations/#vagrant) stack running on your machine.
We will assume that you already have the [Vagrant integration](/current_bw_version/integrations/#vagrant) stack running on your machine.
Once PHP files are copied into the `/var/www/html`folder, you can now edit the `/etc/bunkerweb/variable.env` file :

10
docs/security-tuning.md
View File

@ -1,9 +1,9 @@
# Security tuning
BunkerWeb offers many security features that you can configure with [settings](/1.5.0-beta/settings). Even if the default values of settings ensure a minimal "security by default", we strongly recommend you tune them. By doing so you will be able to ensure the security level of your choice but also manage false positives.
BunkerWeb offers many security features that you can configure with [settings](/current_bw_version/settings). Even if the default values of settings ensure a minimal "security by default", we strongly recommend you tune them. By doing so you will be able to ensure the security level of your choice but also manage false positives.
!!! tip "Other settings"
This section only focuses on security tuning, see the [settings section](/1.5.0-beta/settings) of the documentation for other settings.
This section only focuses on security tuning, see the [settings section](/current_bw_version/settings) of the documentation for other settings.
<figure markdown>
![Overview](assets/img/core-order.svg){ align=center }
@ -98,7 +98,7 @@ Various security headers are available and most of them can be set using BunkerW
STREAM support :x:
[Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) lets you manage how your service can be contacted from different origins. Please note that you will have to allow the `OPTIONS` HTTP method using the `ALLOWED_METHODS` if you want to enable it (more info [here](https://docs.bunkerweb.io/1.5.0-beta/security-tuning/#allowed-methods)). Here is the list of settings related to CORS :
[Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) lets you manage how your service can be contacted from different origins. Please note that you will have to allow the `OPTIONS` HTTP method using the `ALLOWED_METHODS` if you want to enable it (more info [here](https://docs.bunkerweb.io/current_bw_version/security-tuning/#allowed-methods)). Here is the list of settings related to CORS :
| Setting | Default | Context |Multiple| Description |
|------------------------|------------------------------------------------------------------------------------|---------|--------|--------------------------------------------------|
@ -183,7 +183,7 @@ ModSecurity is integrated and enabled by default alongside the OWASP Core Rule S
We strongly recommend keeping both ModSecurity and the OWASP Core Rule Set enabled. The only downsides are the false positives that may occur. But they can be fixed with some efforts and the CRS team maintains a list of exclusions for common applications (e.g., WordPress, Nextcloud, Drupal, Cpanel, ...).
Tuning ModSecurity and the CRS can be done using [custom configurations](/1.5.0-beta/quickstart-guide/#custom-configurations) :
Tuning ModSecurity and the CRS can be done using [custom configurations](/current_bw_version/quickstart-guide/#custom-configurations) :
- modsec-crs : before the OWASP Core Rule Set is loaded
- modsec : after the OWASP Core Rule Set is loaded (also used if CRS is not loaded)
@ -456,7 +456,7 @@ You can quickly protect sensitive resources like the admin area for example, by
### Auth request
You can deploy complex authentication (e.g. SSO), by using the auth request settings (see [here](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication/) for more information on the feature). Please note that you will find [Authelia](https://www.authelia.com/) and [Authentik](https://goauthentik.io/) examples in the [repository](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/examples).
You can deploy complex authentication (e.g. SSO), by using the auth request settings (see [here](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication/) for more information on the feature). Please note that you will find [Authelia](https://www.authelia.com/) and [Authentik](https://goauthentik.io/) examples in the [repository](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/examples).
**Auth request settings are related to reverse proxy rules.**

8
docs/troubleshooting.md
View File

@ -114,7 +114,7 @@ Here is how you can access the logs, depending on your integration :
## Permissions
Don't forget that BunkerWeb runs as an unprivileged user for obvious security reasons. Double-check the permissions of files and folders used by BunkerWeb, especially if you use custom configurations (more info [here](/1.5.0-beta/quickstart-guide/#custom-configurations)). You will need to set at least **RW** rights on files and **_RWX_** on folders.
Don't forget that BunkerWeb runs as an unprivileged user for obvious security reasons. Double-check the permissions of files and folders used by BunkerWeb, especially if you use custom configurations (more info [here](/current_bw_version/quickstart-guide/#custom-configurations)). You will need to set at least **RW** rights on files and **_RWX_** on folders.
## ModSecurity
@ -205,11 +205,11 @@ As we can see, there are 3 different logs :
One important thing to understand is that rule **949110** is not a "real" one : it's the one that will deny the request because the anomaly threshold is reached (which is **10** in this example). You should never remove the **949110** rule !
If it's a false-positive, you should then focus on both **930120** and **932160** rules. ModSecurity and/or CRS tuning is out of the scope of this documentation but don't forget that you can apply custom configurations before and after the CRS is loaded (more info [here](/1.5.0-beta/quickstart-guide/#custom-configurations)).
If it's a false-positive, you should then focus on both **930120** and **932160** rules. ModSecurity and/or CRS tuning is out of the scope of this documentation but don't forget that you can apply custom configurations before and after the CRS is loaded (more info [here](/current_bw_version/quickstart-guide/#custom-configurations)).
## Bad Behavior
A common false-positive case is when the client is banned because of the "bad behavior" feature which means that too many suspicious HTTP status codes were generated within a time period (more info [here](/1.5.0-beta/security-tuning/#bad-behavior)). You should start by reviewing the settings and then edit them according to your web application(s) like removing a suspicious HTTP code, decreasing the count time, increasing the threshold, ...
A common false-positive case is when the client is banned because of the "bad behavior" feature which means that too many suspicious HTTP status codes were generated within a time period (more info [here](/current_bw_version/security-tuning/#bad-behavior)). You should start by reviewing the settings and then edit them according to your web application(s) like removing a suspicious HTTP code, decreasing the count time, increasing the threshold, ...
## IP unban
@ -276,7 +276,7 @@ You can manually unban an IP which can be useful when doing some tests but it ne
## Whitelisting
If you have bots that need to access your website, the recommended way to avoid any false positive is to whitelist them using the [whitelisting feature](/1.5.0-beta/security-tuning/#blacklisting-and-whitelisting). We don't recommend using the `WHITELIST_URI*` or `WHITELIST_USER_AGENT*` settings unless they are set to secret and unpredictable values. Common use cases are :
If you have bots that need to access your website, the recommended way to avoid any false positive is to whitelist them using the [whitelisting feature](/current_bw_version/security-tuning/#blacklisting-and-whitelisting). We don't recommend using the `WHITELIST_URI*` or `WHITELIST_USER_AGENT*` settings unless they are set to secret and unpredictable values. Common use cases are :
- Healthcheck / status bot
- Callback like IPN or webhook

60
docs/web-ui.md
View File

@ -29,11 +29,11 @@ Because the web UI is a web application, the recommended installation procedure
* Choose a strong password for the login
* Put the web UI under a "hard to guess" URI
* Do not open the web UI on the Internet without any further restrictions
* Apply settings listed in the [security tuning section](/1.5.0-beta/security-tuning/) of the documentation
* Apply settings listed in the [security tuning section](/current_bw_version/security-tuning/) of the documentation
!!! info "Multisite mode"
The usage of the web UI implies enabling the [multisite mode](/1.5.0-beta/concepts/#multisite-mode).
The usage of the web UI implies enabling the [multisite mode](/current_bw_version/concepts/#multisite-mode).
=== "Docker"
@ -57,11 +57,11 @@ Because the web UI is a web application, the recommended installation procedure
- `ADMIN_PASSWORD` : password to access the web UI
- `ABSOLUTE_URI` : full URI of your web UI instance (like `http://www.example.com/foo/`)
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/1.5.0-beta/quickstart-guide/#protect-http-applications). We recommend you to connect BunkerWeb and web UI using a dedicated network (like `bw-universe` also used by the scheduler) so it won't be on the same network of your web services for obvious security reasons. Please note that the web UI container is listening on the `7000` port.
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/current_bw_version/quickstart-guide/#protect-http-applications). We recommend you to connect BunkerWeb and web UI using a dedicated network (like `bw-universe` also used by the scheduler) so it won't be on the same network of your web services for obvious security reasons. Please note that the web UI container is listening on the `7000` port.
!!! info "Database backend"
If you want another Database backend than MariaDB please refer to the docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) of the repository.
If you want another Database backend than MariaDB please refer to the docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) of the repository.
Here is the docker-compose boilerplate that you can use (don't forget to edit the `changeme` data) :
@ -70,7 +70,7 @@ Because the web UI is a web application, the recommended installation procedure
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- 80:8080
- 443:8443
@ -95,7 +95,7 @@ Because the web UI is a web application, the recommended installation procedure
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -116,7 +116,7 @@ Because the web UI is a web application, the recommended installation procedure
- bw-docker
bw-ui:
image: bunkerity/bunkerweb-ui:1.5.0-beta
image: bunkerity/bunkerweb-ui:current_bw_version
depends_on:
- bw-docker
environment:
@ -179,11 +179,11 @@ Because the web UI is a web application, the recommended installation procedure
- `ADMIN_PASSWORD` : password to access the web UI
- `ABSOLUTE_URI` : full URI of your web UI instance (like `http://www.example.com/foo/`)
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/1.5.0-beta/quickstart-guide/#protect-http-applications). We recommend you to connect BunkerWeb and web UI using a dedicated network (like `bw-universe` also used by the scheduler and autoconf) so it won't be on the same network of your web services for obvious security reasons. Please note that the web UI container is listening on the `7000` port.
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/current_bw_version/quickstart-guide/#protect-http-applications). We recommend you to connect BunkerWeb and web UI using a dedicated network (like `bw-universe` also used by the scheduler and autoconf) so it won't be on the same network of your web services for obvious security reasons. Please note that the web UI container is listening on the `7000` port.
!!! info "Database backend"
If you want another Database backend than MariaDB please refer to the docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) of the repository.
If you want another Database backend than MariaDB please refer to the docker-compose files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) of the repository.
Here is the docker-compose boilerplate that you can use (don't forget to edit the `changeme` data) :
@ -192,7 +192,7 @@ Because the web UI is a web application, the recommended installation procedure
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- 80:8080
- 443:8443
@ -209,7 +209,7 @@ Because the web UI is a web application, the recommended installation procedure
- bw-services
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:1.5.0-beta
image: bunkerity/bunkerweb-autoconf:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -222,7 +222,7 @@ Because the web UI is a web application, the recommended installation procedure
- bw-docker
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
depends_on:
- bunkerweb
- bw-docker
@ -256,7 +256,7 @@ Because the web UI is a web application, the recommended installation procedure
- bw-docker
bw-ui:
image: bunkerity/bunkerweb-ui:1.5.0-beta
image: bunkerity/bunkerweb-ui:current_bw_version
networks:
bw-docker:
bw-universe:
@ -316,11 +316,11 @@ Because the web UI is a web application, the recommended installation procedure
- `ADMIN_PASSWORD` : password to access the web UI
- `ABSOLUTE_URI` : full URI of your web UI instance (like `http://www.example.com/foo/`)
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/1.5.0-beta/quickstart-guide/#protect-http-applications). We recommend you to connect BunkerWeb and web UI using a dedicated network (like `bw-universe` also used by the scheduler and autoconf) so it won't be on the same network of your web services for obvious security reasons. Please note that the web UI container is listening on the `7000` port.
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/current_bw_version/quickstart-guide/#protect-http-applications). We recommend you to connect BunkerWeb and web UI using a dedicated network (like `bw-universe` also used by the scheduler and autoconf) so it won't be on the same network of your web services for obvious security reasons. Please note that the web UI container is listening on the `7000` port.
!!! info "Database backend"
If you want another Database backend than MariaDB please refer to the stack files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) of the repository.
If you want another Database backend than MariaDB please refer to the stack files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) of the repository.
Here is the stack boilerplate that you can use (don't forget to edit the `changeme` data) :
@ -329,7 +329,7 @@ Because the web UI is a web application, the recommended installation procedure
services:
bunkerweb:
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
ports:
- published: 80
target: 8080
@ -359,7 +359,7 @@ Because the web UI is a web application, the recommended installation procedure
- "bunkerweb.INSTANCE"
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:1.5.0-beta
image: bunkerity/bunkerweb-autoconf:current_bw_version
environment:
- SWARM_MODE=yes
- DOCKER_HOST=tcp://bw-docker:2375
@ -386,7 +386,7 @@ Because the web UI is a web application, the recommended installation procedure
- "node.role == manager"
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
environment:
- SWARM_MODE=yes
- DOCKER_HOST=tcp://bw-docker:2375
@ -413,7 +413,7 @@ Because the web UI is a web application, the recommended installation procedure
- bw-universe
bw-ui:
image: bunkerity/bunkerweb-ui:1.5.0-beta
image: bunkerity/bunkerweb-ui:current_bw_version
environment:
- DATABASE_URI=mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db # Remember to set a stronger password for the database
- DOCKER_HOST=tcp://bw-docker:2375
@ -465,11 +465,11 @@ Because the web UI is a web application, the recommended installation procedure
- `ADMIN_PASSWORD` : password to access the web UI
- `ABSOLUTE_URI` : full URI of your web UI instance (like `http://www.example.com/foo/`)
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/1.5.0-beta/quickstart-guide/#protect-http-applications). Network segmentation between web UI and web services is not covered in this documentation. Please note that the web UI container is listening on the `7000` port.
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/current_bw_version/quickstart-guide/#protect-http-applications). Network segmentation between web UI and web services is not covered in this documentation. Please note that the web UI container is listening on the `7000` port.
!!! info "Database backend"
If you want another Database backend than MariaDB please refer to the yaml files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/1.5.0-beta/misc/integrations) of the repository.
If you want another Database backend than MariaDB please refer to the yaml files in the [misc/integrations folder](https://github.com/bunkerity/bunkerweb/tree/vcurrent_bw_version/misc/integrations) of the repository.
Here is the yaml boilerplate that you can use (don't forget to edit the `changeme` data) :
@ -523,7 +523,7 @@ Because the web UI is a web application, the recommended installation procedure
spec:
containers:
- name: bunkerweb
image: bunkerity/bunkerweb:1.5.0-beta
image: bunkerity/bunkerweb:current_bw_version
imagePullPolicy: Always
securityContext:
runAsUser: 101
@ -593,7 +593,7 @@ Because the web UI is a web application, the recommended installation procedure
serviceAccountName: sa-bunkerweb
containers:
- name: bunkerweb-controller
image: bunkerity/bunkerweb-autoconf:1.5.0-beta
image: bunkerity/bunkerweb-autoconf:current_bw_version
imagePullPolicy: Always
env:
- name: KUBERNETES_MODE
@ -620,7 +620,7 @@ Because the web UI is a web application, the recommended installation procedure
serviceAccountName: sa-bunkerweb
containers:
- name: bunkerweb-scheduler
image: bunkerity/bunkerweb-scheduler:1.5.0-beta
image: bunkerity/bunkerweb-scheduler:current_bw_version
imagePullPolicy: Always
env:
- name: KUBERNETES_MODE
@ -704,7 +704,7 @@ Because the web UI is a web application, the recommended installation procedure
spec:
containers:
- name: bunkerweb-ui
image: bunkerity/bunkerweb-ui:1.5.0-beta
image: bunkerity/bunkerweb-ui:current_bw_version
imagePullPolicy: Always
env:
- name: ADMIN_USERNAME
@ -805,7 +805,7 @@ Because the web UI is a web application, the recommended installation procedure
=== "Linux"
The installation of the web UI using the [Linux integration](/1.5.0-beta/integrations/#linux) is pretty straightforward because it is installed with BunkerWeb.
The installation of the web UI using the [Linux integration](/current_bw_version/integrations/#linux) is pretty straightforward because it is installed with BunkerWeb.
The web UI comes as systemd service named `bunkerweb-ui` which is not enabled by default. If you want to start the web UI when on startup you can run the following command :
@ -827,7 +827,7 @@ Because the web UI is a web application, the recommended installation procedure
systemctl restart bunkerweb-ui
```
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/1.5.0-beta/quickstart-guide/#protect-http-applications). Please note that the web UI is listening on the `7000` port and only on the loopback interface.
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/current_bw_version/quickstart-guide/#protect-http-applications). Please note that the web UI is listening on the `7000` port and only on the loopback interface.
Here is the `/etc/bunkerweb/variables.env` boilerplate you can use :
@ -853,7 +853,7 @@ Because the web UI is a web application, the recommended installation procedure
=== "Ansible"
The installation of the web UI using the [Vagrant integration](/1.5.0-beta/integrations/#linux) is pretty straightforward because it is installed with BunkerWeb.
The installation of the web UI using the [Vagrant integration](/current_bw_version/integrations/#linux) is pretty straightforward because it is installed with BunkerWeb.
Create a `my_ui.env` filed used to configure the web UI :
@ -908,7 +908,7 @@ Because the web UI is a web application, the recommended installation procedure
=== "Vagrant"
The installation of the web UI using the [Vagrant integration](/1.5.0-beta/integrations/#vagrant) is pretty straightforward because it is installed with BunkerWeb.
The installation of the web UI using the [Vagrant integration](/current_bw_version/integrations/#vagrant) is pretty straightforward because it is installed with BunkerWeb.
First of all, you will need to get a shell on your Vagrant box :
@ -936,7 +936,7 @@ Because the web UI is a web application, the recommended installation procedure
systemctl restart bunkerweb-ui
```
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/1.5.0-beta/quickstart-guide/#protect-http-applications). Please note that the web UI is listening on the `7000` port and only on the loopback interface.
Accessing the web UI through BunkerWeb is a classical [reverse proxy setup](/current_bw_version/quickstart-guide/#protect-http-applications). Please note that the web UI is listening on the `7000` port and only on the loopback interface.
Here is the `/etc/bunkerweb/variables.env` boilerplate you can use :

3
mkdocs.yml
View File

@ -36,6 +36,9 @@ theme:
extra_css:
- assets/extra.css
extra_javascript:
- assets/extra.js
markdown_extensions:
- attr_list
- md_in_html

13
src/linux/scripts/postinstall.sh
View File

@ -98,18 +98,19 @@ fi
# Create letsencrypt folders if needed
if [ ! -d /etc/letsencrypt ] ; then
mkdir /etc/letsencrypt
chown nginx:nginx /etc/letsencrypt
chmod 770 /etc/letsencrypt
fi
chown nginx:nginx /etc/letsencrypt
chmod 770 /etc/letsencrypt
if [ ! -d /var/lib/letsencrypt ] ; then
mkdir /var/lib/letsencrypt
chown nginx:nginx /var/lib/letsencrypt
chmod 770 /var/lib/letsencrypt
fi
chown nginx:nginx /var/lib/letsencrypt
chmod 770 /var/lib/letsencrypt
if [ ! -d /var/log/letsencrypt ] ; then
mkdir /var/log/letsencrypt
chown nginx:nginx /var/log/letsencrypt
chmod 770 /var/log/letsencrypt
fi
chown nginx:nginx /var/log/letsencrypt
chmod 770 /var/log/letsencrypt
echo "Postinstall successful !"