This repository contains all files to automatically configure and set up a local demo environment, consisting of a CI/CD GitLab Community Edition server and multiple (Docker-in-Docker) GitLab runners. Optionally, SonarQube Community Edition and Dependency-Track can be configured and set up as well.
Have curl
, docker
, and docker-compose
installed.
./installer.sh
This will fire up an instance of GitLab and two GitLab runners, capable of performing Docker-in-Docker commands.
All variables are stored in an .env
file: The .env
file itself not supplied
in this repository, but an example is. If you don't create an .env
file before
using the installer, it will automatically copy and use the env-example
file
for you.
Then, you'll need to register the (group of) runners with a valid runner token,
which needs to be created manually: In GitLab, go to the Admin Area / Dashboard,
click on Instant Runners, and click on New instance runner
(/admin/runners/new
). Select "Run untagged jobs" and click on Create runner.
This will generate a new runner token. Copy the token.
Lastly, execute the register-runners.sh
script with that token as parameter.
This script will register all runners that are up and running.
./installer.sh sonarqube
./installer.sh dependency-track
./installer.sh stop
docker-compose down
By default all data, configuration and logs will be stored in persistent Docker volumes. They will remain, even if you stop or remove the Docker containers. To clean everything up, remove the containers including named volumes.
docker-compose down --remove-orphans --volumes
Please note that this is a lab setup - and not meant to be used in production in
any way. All services only bind / listen to 127.0.0.1
by default (this can be
changed in the file docker-compose
.
Furthermore all runners share one named Docker volume as cache under
/srv/cache
. This named volume will be initialized by default, and has lax
permissions (to ensure all tools can work with it).
Furthermore, the repository contains a number of pipeline example scripts, to help you add several automated security testing tools to a GitLab pipeline. The pipeline definition files can be found in the folder juice-shop:
- Basic build pipeline
- Detecting secrets in a code base with detect-secrets
- Dockerfile linting with Hadolint
- SAST with Njsscan
- SAST with SonarQube
- Software composition analysis with Dependency-Check
- Component analysis with Dependency-Track
- Container vulnerability scanning with Trivy
- DAST with ZAP
- DAST with Nikto
- Full automated security testing
The DEMO_NAME
allows you to run multiple instances of this demo on the same
machine, as it will generate its own "Docker namespace".
DIND_VERSION
defines the Docker-in-Docker image tag being used.
DTRACK_API_PORT
defines the port number of the Dependency-Track API interface.
DTRACK_API_VERSION
defines the Dependency-Track API image tag.
DTRACK_FRONTEND_PORT
defines the port number on which the web interface of
Dependency-Track will be accessible.
DTRACK_FRONTEND_VERSION
defines the Dependency-Track frontend image tag.
GITLAB_HOSTNAME
defines the hostname that will be used to access GitLab.
Please note that this name needs to be resolved, see the remarks at the bottom
of this page.
GITLAB_PASSWORD
defines the initial password for user root
.
GITLAB_PORT
defines the port number on which the web interface of GitLab will
be accessible.
GITLAB_SSH
defines the SSH port number for GitLab.
GITLAB_VERSION
defines the GitLab image tag being used. Please note that the
runners always use the latest version.
SONARQUBE_HOSTNAME
defines the hostname that will be used to access SonarQube.
Please note that this name needs to be resolved, see the remarks at the bottom
of this page.
SONARQUBE_PASSWORD
defines the initial password for user admin
.
SONARQUBE_PLUGINS
defines a space-delimited list of SonarQube plugins that
will be installed at first startup.
SONARQUBE_PORT
defines the port number on which the web interface of SonarQube
will be accessible.
SONARQUBE_VERSION
allows you to specify which SonarQube image you would like
to use.
Important!
The GITLAB_PASSWORD needs to be complex, otherwise installation will fail, see https://about.gitlab.com/handbook/security/password-standard.html.
If you want to access the web interfaces using "pretty host names" that are
defined using GITLAB_HOSTNAME
and SONARQUBE_HOSTNAME
(instead of
localhost
), then make sure that they can be resolved by your browser. This can
be done for instance by adding them to your local hosts
file.
Great that you're using this code, hopefully you find it useful! All that I'm asking is that you properly attribute the author (Peter Mosmans), and respect the GPLv3 license.