Project Name | Stars | Downloads | Repos Using This | Packages Using This | Most Recent Commit | Total Releases | Latest Release | Open Issues | License | Language |
---|---|---|---|---|---|---|---|---|---|---|
Devops Exercises | 58,358 | 2 days ago | 53 | other | Python | |||||
Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. DevOps Interview Questions | ||||||||||
Gogs | 42,996 | 4 | 2 days ago | 74 | February 25, 2023 | 880 | mit | Go | ||
Gogs is a painless self-hosted Git service | ||||||||||
Gitness | 29,407 | an hour ago | 126 | apache-2.0 | Go | |||||
Gitness is an Open Source developer platform with Source Control management, Continuous Integration and Continuous Delivery. | ||||||||||
Onedev | 11,923 | 12 hours ago | other | Java | ||||||
Self-hosted Git Server with CI/CD and Kanban | ||||||||||
Docker Gitlab | 7,650 | 2 days ago | 539 | mit | Shell | |||||
Dockerized GitLab | ||||||||||
Devops Guide | 7,140 | a day ago | 10 | mit | HTML | |||||
DevOps Guide - Development to Production all configurations with basic notes to debug efficiently. | ||||||||||
Sftpgo | 6,788 | 6 | 9 days ago | 49 | July 14, 2023 | 18 | agpl-3.0 | Go | ||
Fully featured and highly configurable SFTP server with optional HTTP/S, FTP/S and WebDAV support - S3, Google Cloud Storage, Azure Blob | ||||||||||
Docker Ce | 5,554 | 16 | a year ago | 42 | April 23, 2021 | 2 | apache-2.0 | Go | ||
:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning: | ||||||||||
K8s_paas | 3,818 | 2 months ago | 7 | mit | Shell | |||||
如何基于K8s(Kubernetes)部署成PaaS/DevOps(一套完整的软件研发和部署平台)--教程/学习(实战代码/欢迎讨论/大量注释/操作配图),你将习得部署如:K8S(Kubernetes)、Dashboard、Harbor、Jenkins、本地Gitlab、Apollo框架、Promtheus、Grafana、Spinnaker等。 | ||||||||||
Awesome Programming Books | 3,649 | a year ago | 4 | |||||||
📚 经典技术书籍推荐,持续更新... |
Captain - Convert your Git workflow to Docker containers ready for Continuous Delivery
Define your workflow in the captain.yaml
and use captain to your Continuous Delivery service to create containers for each commit, test them and push them to your registry only when tests passes.
captain build
to build your Dockerfile(s) of your repository. If your repository has local changes the containers will only be tagged as latest, otherwise the containers will be tagged as latest, COMMIT_ID & BRANCH_NAME. Now your Git commit tree is reproduced in your local docker repository.captain test
to run your testscaptain push
to send selected images to the remote repositoryFrom the other side, you can now pull the feature branch you want to test, or create distribution channels (such as 'alpha', 'beta', 'stable') using git tags that are propagated to container tags.
To install Captain, run:
curl -sSL https://raw.githubusercontent.com/harbur/captain/v1.1.3/install.sh | bash
You will need to add ~/.captain/bin
in your PATH
. E.g. in your .bashrc
or .zshrc
add:
export PATH=$HOME/.captain/bin:$PATH
Captain will automatically configure itself with sane values without the need for any pre-configuration, so that it will work in most cases. When it doesn't, the captain.yml
file can be used to configure it properly. This is a simple YAML file placed on the root directory of your git repository. Captain will look for it and use it to be configured.
Here is a full captain.yml
example:
hello-world:
build: Dockerfile
image: harbur/hello-world
pre:
- echo "Preparing hello-world"
post:
- echo "Finished hello-world"
hello-world-test:
build: Dockerfile.test
image: harbur/hello-world-test
pre:
- echo "Preparing hello-world-test"
post:
- echo "Finished hello-world-test"
test:
- docker run -e NODE_ENV=TEST harbur/hello-world-test node mochaTest
- docker run -e NODE_ENV=TEST harbur/hello-world-test node karmaTest
project-with-build-args:
build: Dockerfile
image: harbur/buildargs
build_arg:
keyname: keyvalue
The location of the Dockerfile to be compiled.
When auto-detecting, the image will be re-constructed by the following rules:
Dockerfile
: username
/parent_dir
Dockerfile.*
: username
/parent_dir
.parsed_suffix
Where
username
is the host's usernameparent_dir
is the Dockerfile's parent directory nameparsed_suffix
: is the suffix of the Dockerfile parsed with the following rules:
image: harbur/hello-world
The relative path of the Dockerfile to be used to compile the image. The Dockerfile's directory is also the build context that is sent to the Docker daemon.
When auto-detecting it will walk current directory and all subdirectories to locate Dockerfiles of the following format:
Dockerfile
Dockerfile.*
The build path will be reconstructed automatically to compile the Dockerfile. The build context will be the directory where the Dockerfile is located.
Note: If more than one Dockerfiles are needed on specific directory, suffix can be used to separate them and share the same build context.
build: Dockerfile
build: Dockerfile.custom
build: path/to/file/Dockerfile
build: path/to/file/Dockerfile.custom
A list of commands that are run as tests after the compilation of the specific image. If any command fail, then captain stops and reports a non-zero exit status.
test:
- docker run -e NODE_ENV=TEST harbur/hello-world-test node mochaTest
- docker run -e NODE_ENV=TEST harbur/hello-world-test node karmaTest
A list of commands that are run as preparation before the compilation of the specific image. If any command fail, then captain stops and reports a non-zero exit status.
pre:
- echo "Preparing compilation"
A list of commands that are run as post-execution after the compilation of the specific image. If any command fail, then captain stops and reports a non-zero exit status.
post:
- echo "Reporting after compilation"
A set of key values that are passed to docker build as --build-arg
flag. For more information about build-args see here.
build_arg:
keyname: keyvalue
Builds the docker image(s) of your repository
It will build the docker image(s) described on captain.yml in order they appear on file
Flags:
-B, --all-branches=false: Build all branches on specific commit instead of just working branch
-f, --force=false: Force build even if image is already built
Runs the tests
It will execute the commands described on test section in order they appear on file
Pushes the images to remote registry
It will push the generated images to the remote registry
By default it pushes the 'latest' and the 'branch' docker tags.
Flags:
-B, --all-branches=false: Push all branches on specific commit instead of just working branch
-b, --branch-tags=true: Push the 'branch' docker tags
-c, --commit-tags=false: Push the 'commit' docker tags
Pulls the images from remote registry
It will pull the images from the remote registry
By default it pulls the 'latest' and the 'branch' docker tags.
Flags:
-B, --all-branches=false: Pull all branches on specific commit instead of just working branch
-b, --branch-tags=true: Pull the 'branch' docker tags
-c, --commit-tags=false: Pull the 'commit' docker tags
Updates Captain to the last available version.
Display version
Displays the version of Captain
Help provides help for any command in the application.
Simply type captain help [path to command]
for full details.
-D, --debug=false: Enable debug mode
-h, --help=false: help for captain
-N, --namespace="username": Set default image namespace
The following is the workflow of tagging Docker images according to git state.
latest
.latest
.latest
, commit-id
, branch-name
, tag-name
. A maximum of one tag per commit id is supported.Here are some of the features pending to be implemented:
captain detect
that outputs the generated captain.yml
with auto-detected content.captain ci [travis|circle|etc.]
to output configuration wrappers for each CI service