SHIP: Shell Helper to Initialize (dockerfiles) in a new Project: https://github.com/augustohp/ship
#docker
  
  
  
  
  
  #docker
🐋 Keep an eye on your #docker image size and prevent it from growing too big: https://github.com/wemake-services/docker-image-size-limit
  
  
  
  
  
  Github Action to prevent cursing in issues and pull requests: https://github.com/sobolevn/restrict-cursing-action
#js #typescript #docker
  
  
  
  
  
  #js #typescript #docker
Yesterday, Mirantis acquired Docker Enterprise which includes the registry, the enterprise accounts and basically everything of value owned by Docker Inc. The company is now left with a shell of its former business. Even though the sale amount is not public, it is widely understood to not be a large sum.
#docker was once a darling of the tech world. Today we are left wondering - Who ate their lunch?
  #docker was once a darling of the tech world. Today we are left wondering - Who ate their lunch?
This is insane! This utility strips everything you do not need from an image and creates a new image with just the bare necessities.
Look at the image size!
https://github.com/mvanholsteijn/strip-docker-image
But, it surely won't work for complex app images.
#devops #docker
  
  
  
  
  
  Look at the image size!
https://github.com/mvanholsteijn/strip-docker-image
But, it surely won't work for complex app images.
#devops #docker
Quay: Build, Store, and Distribute your Applications and Containers.
High-level features include:
- Docker Registry Protocol v2
- Docker Manifest Schema v2.1, v2.2
- AppC Image Discovery via on-demand transcoding
- Image Squashing via on-demand transcoding
- Authentication provided by LDAP, Keystone, OIDC, Google, and GitHub
- ACLs, team management, and auditability logs
- Geo-replicated storage provided by local filesystems, S3, GCS, Swift, and Ceph
- Continuous Integration integrated with GitHub, Bitbucket, GitLab, and git
- Security Vulnerability Analysis via Clair 🔥
- Swagger-compliant HTTP API
https://github.com/quay/quay
#devops #docker
  
  
  
  
  
  High-level features include:
- Docker Registry Protocol v2
- Docker Manifest Schema v2.1, v2.2
- AppC Image Discovery via on-demand transcoding
- Image Squashing via on-demand transcoding
- Authentication provided by LDAP, Keystone, OIDC, Google, and GitHub
- ACLs, team management, and auditability logs
- Geo-replicated storage provided by local filesystems, S3, GCS, Swift, and Ceph
- Continuous Integration integrated with GitHub, Bitbucket, GitLab, and git
- Security Vulnerability Analysis via Clair 🔥
- Swagger-compliant HTTP API
https://github.com/quay/quay
#devops #docker
One more tool to minify #docker images: https://github.com/docker-slim/docker-slim
Don't change anything in your Docker container image and minify it by up to 30x making it secure too!
Don't worry about manually creating Seccomp and AppArmor security profiles. You shouldn't have to become an expert in Linux syscalls, Seccomp and AppArmor to have secure containers. Even if you do know enough about it wasting time reverse engineering your application behavior can be time-consuming.
docker-slim will optimize and secure your containers by understanding your application and what it needs using various analysis techniques. It will throw away what you don't need, reducing the attack surface of your container. What if you need some of those extra things to debug your container? You can use dedicated debugging side-car containers for that (more details below).
Some results:
- from node:alpine - 66.7MB => 34.7MB (minified by 1.92X)
- from python:2.7-alpine - 84.3MB => 23.1MB (minified by 3.65X)
#devops
  
  Don't change anything in your Docker container image and minify it by up to 30x making it secure too!
Don't worry about manually creating Seccomp and AppArmor security profiles. You shouldn't have to become an expert in Linux syscalls, Seccomp and AppArmor to have secure containers. Even if you do know enough about it wasting time reverse engineering your application behavior can be time-consuming.
docker-slim will optimize and secure your containers by understanding your application and what it needs using various analysis techniques. It will throw away what you don't need, reducing the attack surface of your container. What if you need some of those extra things to debug your container? You can use dedicated debugging side-car containers for that (more details below).
Some results:
- from node:alpine - 66.7MB => 34.7MB (minified by 1.92X)
- from python:2.7-alpine - 84.3MB => 23.1MB (minified by 3.65X)
#devops
GitHub
  
  GitHub - slimtoolkit/slim: Slim(toolkit): Don't change anything in your container image and minify it by up to 30x (and for compiled…
  Slim(toolkit): Don't change anything in your container image and minify it by up to 30x (and for compiled languages even more) making it secure too! (free and open source) - slimtoolkit/slim
  A process for automating #docker container base image updates.
With watchtower you can update the running version of your containerized app simply by pushing a new image to the Docker Hub or your own image registry. Watchtower will pull down your new image, gracefully shut down your existing container and restart it with the same options that were used when it was deployed initially. Run the watchtower container with the following command:
https://github.com/containrrr/watchtower
#go #devops
  
  With watchtower you can update the running version of your containerized app simply by pushing a new image to the Docker Hub or your own image registry. Watchtower will pull down your new image, gracefully shut down your existing container and restart it with the same options that were used when it was deployed initially. Run the watchtower container with the following command:
docker run -d \
--name watchtower \
-v /var/run/docker.sock:/var/run/docker.sock \
containrrr/watchtower
https://github.com/containrrr/watchtower
#go #devops
GitHub
  
  GitHub - containrrr/watchtower: A process for automating Docker container base image updates.
  A process for automating Docker container base image updates.  - GitHub - containrrr/watchtower: A process for automating Docker container base image updates.
  Homebrew, but with #docker images.
Whalebrew creates aliases for Docker images so you can run them as if they were native commands. It's like Homebrew, but with Docker images.
Docker works well for packaging up development environments, but there are lots of tools that aren't tied to a particular project: awscli for managing your AWS account, ffmpeg for converting video, wget for downloading files, and so on. Whalebrew makes those things work with Docker, too.
https://github.com/whalebrew/whalebrew
#macos #devops
  
  
  
  
  
  Whalebrew creates aliases for Docker images so you can run them as if they were native commands. It's like Homebrew, but with Docker images.
Docker works well for packaging up development environments, but there are lots of tools that aren't tied to a particular project: awscli for managing your AWS account, ffmpeg for converting video, wget for downloading files, and so on. Whalebrew makes those things work with Docker, too.
https://github.com/whalebrew/whalebrew
#macos #devops
Litmus helps Kubernetes SREs and developers practice chaos engineering in a Kubernetes native way.
Litmus is a toolset to do cloud-native chaos engineering. Litmus provides tools to orchestrate chaos on #k8s to help SREs find weaknesses in their deployments. SREs use Litmus to run chaos experiments initially in the staging environment and eventually in production to find bugs, vulnerabilities. Fixing the weaknesses leads to increased resilience of the system.
Litmus takes a cloud-native approach to create, manage and monitor chaos. Chaos is orchestrated using the following Kubernetes Custom Resource Definitions (CRDs):
- ChaosEngine: A resource to link a Kubernetes application or Kubernetes node to a ChaosExperiment. ChaosEngine is watched by Litmus' Chaos-Operator which then invokes Chaos-Experiments
- ChaosExperiment: A resource to group the configuration parameters of a chaos experiment. ChaosExperiment CRs are created by the operator when experiments are invoked by ChaosEngine.
- ChaosResult: A resource to hold the results of a chaos-experiment. The Chaos-exporter reads the results and exports the metrics into a configured Prometheus server.
Chaos experiments are hosted on hub.litmuschaos.io. It is a central hub where the application developers or vendors share their chaos experiments so that their users can use them to increase the resilience of the applications in production.
https://github.com/litmuschaos/litmus
#docker #devops #ts #go
  
  
  
  
  
  Litmus is a toolset to do cloud-native chaos engineering. Litmus provides tools to orchestrate chaos on #k8s to help SREs find weaknesses in their deployments. SREs use Litmus to run chaos experiments initially in the staging environment and eventually in production to find bugs, vulnerabilities. Fixing the weaknesses leads to increased resilience of the system.
Litmus takes a cloud-native approach to create, manage and monitor chaos. Chaos is orchestrated using the following Kubernetes Custom Resource Definitions (CRDs):
- ChaosEngine: A resource to link a Kubernetes application or Kubernetes node to a ChaosExperiment. ChaosEngine is watched by Litmus' Chaos-Operator which then invokes Chaos-Experiments
- ChaosExperiment: A resource to group the configuration parameters of a chaos experiment. ChaosExperiment CRs are created by the operator when experiments are invoked by ChaosEngine.
- ChaosResult: A resource to hold the results of a chaos-experiment. The Chaos-exporter reads the results and exports the metrics into a configured Prometheus server.
Chaos experiments are hosted on hub.litmuschaos.io. It is a central hub where the application developers or vendors share their chaos experiments so that their users can use them to increase the resilience of the applications in production.
https://github.com/litmuschaos/litmus
#docker #devops #ts #go
Build automation for the post-container era. It's like Makefile and Dockerfile had a baby.
Earthly is a build automation tool for the post-container era. It allows you to execute all your builds in containers. This makes them self-contained, reproducible, portable and parallel. You can use Earthly to create Docker images and artifacts (eg binaries, packages, arbitrary files).
Earthly is meant to be used both on your development machine and in CI. It can run on top of popular CI systems (like Jenkins, Circle, GitHub Actions). It is typically the layer between language-specific tooling (like maven, gradle, npm, pip, go build) and the CI build spec.
Features:
- Reproduce CI failures
- Builds that run the same for everyone
- From zero to working build in minutes
- Build anything via containers - build images or standalone artifacts (binaries, packages, arbitrary files)
- Programming language agnostic - allows use of language-specific build tooling
- Reproducible builds - does not depend on user's local installation. Runs the same locally, as in CI
- Parallelism that just works - builds in parallel without special considerations the user has to make
- Mono-repo friendly - ability to split the build definitions across a vast directory hierarchy
- Multi-repo friendly - ability to import builds or artifacts from other repositories
https://github.com/earthly/earthly
#docker #devops #go
Example:
Output:
  
  
  Earthly is a build automation tool for the post-container era. It allows you to execute all your builds in containers. This makes them self-contained, reproducible, portable and parallel. You can use Earthly to create Docker images and artifacts (eg binaries, packages, arbitrary files).
Earthly is meant to be used both on your development machine and in CI. It can run on top of popular CI systems (like Jenkins, Circle, GitHub Actions). It is typically the layer between language-specific tooling (like maven, gradle, npm, pip, go build) and the CI build spec.
Features:
- Reproduce CI failures
- Builds that run the same for everyone
- From zero to working build in minutes
- Build anything via containers - build images or standalone artifacts (binaries, packages, arbitrary files)
- Programming language agnostic - allows use of language-specific build tooling
- Reproducible builds - does not depend on user's local installation. Runs the same locally, as in CI
- Parallelism that just works - builds in parallel without special considerations the user has to make
- Mono-repo friendly - ability to split the build definitions across a vast directory hierarchy
- Multi-repo friendly - ability to import builds or artifacts from other repositories
https://github.com/earthly/earthly
#docker #devops #go
Example:
# Earthfile
FROM golang:1.13-alpine3.11
RUN apk --update --no-cache add git
WORKDIR /go-example
all:
BUILD +lint
BUILD +docker
build:
COPY main.go .
RUN go build -o build/go-example main.go
SAVE ARTIFACT build/go-example AS LOCAL build/go-example
lint:
RUN go get golang.org/x/lint/golint
COPY main.go .
RUN golint -set_exit_status ./...
docker:
COPY +build/go-example .
ENTRYPOINT ["/go-example/go-example"]
SAVE IMAGE go-example:latest
Output:
concise commandline monitoring for containers.
Top-like interface for container metrics. ctop comes with built-in support for Docker and runC. As well as a single container view for inspecting a specific container.
Connectors for other container and cluster systems are planned for future releases.
https://github.com/bcicen/ctop
#go #devops #docker
  
  
  Top-like interface for container metrics. ctop comes with built-in support for Docker and runC. As well as a single container view for inspecting a specific container.
Connectors for other container and cluster systems are planned for future releases.
https://github.com/bcicen/ctop
#go #devops #docker
Put your Nginx inside a bunker! nginx Docker image secure by default.
Avoid the hassle of following security best practices each time you need a web server or reverse proxy. Bunkerized-nginx provides generic security configs, settings and tools so you don't need to do it yourself.
Non-exhaustive list of features :
- HTTPS support with transparent Let's Encrypt automation
- State-of-the-art web security : HTTP security headers, php.ini hardening, prevent leaks, ...
- Integrated ModSecurity WAF with the OWASP Core Rule Set
- Automatic ban of strange behaviors with fail2ban
- Antibot challenge through cookie, javascript, captcha or recaptcha v3
- Block TOR, proxies, bad user-agents, countries, ...
- Perform automatic DNSBL checks to block known bad IP
- Prevent bruteforce attacks with rate limiting
- Detect bad files with ClamAV
- Easy to configure with environment variables
https://github.com/bunkerity/bunkerized-nginx
#devops #docker
  
  Avoid the hassle of following security best practices each time you need a web server or reverse proxy. Bunkerized-nginx provides generic security configs, settings and tools so you don't need to do it yourself.
Non-exhaustive list of features :
- HTTPS support with transparent Let's Encrypt automation
- State-of-the-art web security : HTTP security headers, php.ini hardening, prevent leaks, ...
- Integrated ModSecurity WAF with the OWASP Core Rule Set
- Automatic ban of strange behaviors with fail2ban
- Antibot challenge through cookie, javascript, captcha or recaptcha v3
- Block TOR, proxies, bad user-agents, countries, ...
- Perform automatic DNSBL checks to block known bad IP
- Prevent bruteforce attacks with rate limiting
- Detect bad files with ClamAV
- Easy to configure with environment variables
https://github.com/bunkerity/bunkerized-nginx
#devops #docker
GitHub
  
  GitHub - bunkerity/bunkerweb: 🛡️ Open-source and next-generation Web Application Firewall (WAF)
  🛡️ Open-source and next-generation Web Application Firewall (WAF) - bunkerity/bunkerweb
  Keep an eye on your #docker image size and prevent it from growing too big!
Limit your docker image size with a simple CLI command. Perfect to be used inside your CI process.
Also available as a Github Action.
https://github.com/wemake-services/docker-image-size-limit
#python
  
  
  
  
  
  Limit your docker image size with a simple CLI command. Perfect to be used inside your CI process.
Also available as a Github Action.
https://github.com/wemake-services/docker-image-size-limit
#python
So, after recent 
This forced me to create our own dind image (https://github.com/wemake-services/wemake-dind/) with everything properly set up: python, rust (required to build `cryptography`), docker-compose, and several #docker quality tools like:
- https://github.com/wemake-services/dump-env which enforces strict .env configuration policies
- https://github.com/wemake-services/docker-image-size-limit which enforces strict image size control
Feel free to use it in your own CI pipelines! Not just for python, but for any docker-in-docker setups that use
  
  cryptography incident (https://github.com/pyca/cryptography/issues/5771) our build-times inside the Alpine-based docker-in-docker CI went from several seconds to ~6 minutes just to install #python dependencies.This forced me to create our own dind image (https://github.com/wemake-services/wemake-dind/) with everything properly set up: python, rust (required to build `cryptography`), docker-compose, and several #docker quality tools like:
- https://github.com/wemake-services/dump-env which enforces strict .env configuration policies
- https://github.com/wemake-services/docker-image-size-limit which enforces strict image size control
Feel free to use it in your own CI pipelines! Not just for python, but for any docker-in-docker setups that use
docker-compose.GitHub
  
  Dependency on rust removes support for a number of platforms · Issue #5771 · pyca/cryptography
  I would like to report that the newly added dependency on Rust has made it impossible to package cryptography for a number of supported Gentoo architectures (and these are architectures where peopl...