thaJeztah

# Generate a new pgp key: (better to use gpg2 instead of gpg in all below commands)
gpg --gen-key
# maybe you need some random work in your OS to generate a key. so run this command: `find ./* /home/username -type d | xargs grep some_random_string > /dev/null`

# check current keys:
gpg --list-secret-keys --keyid-format LONG

# See your gpg public key:
gpg --armor --export YOUR_KEY_ID
# YOUR_KEY_ID is the hash in front of `sec` in previous command. (for example sec 4096R/234FAA343232333 => key id is: 234FAA343232333)

thaJeztah

# Source: http://frippery.org/busybox/
# This Dockerfile builds a (32-bit) busybox images which is suitable for
# running many of the integration-cli tests for Docker against a Windows
# daemon. It will not run on nanoserver as that is 64-bit only.
#
# John Howard (IRC jhowardmsft, Email john.howard@microsoft.com)
#
# To build: docker build -t busybox .
# To publish: Needs someone with publishing rights
#

thaJeztah

#!/bin/bash

# Example for the Docker Hub V2 API
# Returns all imagas and tags associated with a Docker Hub user account.
# Requires 'jq': https://stedolan.github.io/jq/

# set username and password
UNAME=""
UPASS=""

thaJeztah

Docker Changelog CLI plugin

Based on a tweet by @Tomwillfixit

Just a quick fun conversion to make it work as a Docker CLI plugin

• docker/cli#1534 CLI Plugins Design
• docker/cli#1564 Basic framework for writing and running CLI plugins

To use it (assuming you're running a beta of Docker 19.03):

thaJeztah

Run Docker Compose as a Docker CLI plugin

Just a quick fun experiment to try to make docker-compose work as a Docker CLI plugin

• docker/cli#1534 CLI Plugins Design
• docker/cli#1564 Basic framework for writing and running CLI plugins

To use it (assuming you have docker compose installed):

1. download a and install nightly build of the docker cli (linux macOS)

thaJeztah

Git cheat list

• stashing everything except staged changes:

  git stash -ku
  

• fixing dates and authors in the commits:

  git rebase -i HEAD~<NUMBER_OF_LAST_COMMITS_TO_REBASE>
  

thaJeztah

Silly experiments with RUN --mount

relates to moby/moby#32507, moby/buildkit#442

Doing some silly experimenting with RUN --mount:

# syntax=docker/dockerfile:1

FROM alpine AS stage1

thaJeztah

#!/bin/bash

# Downloads and applies a patch from Drupal.org.
if [ -z "$1" ] 
then
  echo "You need to supply a URL to a patch file."
  exit
fi

URL=$1;

thaJeztah

Keybase proof

I hereby claim:

• I am thajeztah on github.
• I am thajeztah (https://keybase.io/thajeztah) on keybase.
• I have a public key ASAg7yCbSkogz_Lm5I7eNReLoVx_9WYeJr7bULRs54xY7go

To claim this, I am signing this object:

thaJeztah

Cross-compose network connections

When running a compose project, services are accessible both through their full name (including the project-name prefix, for example, myproject_web_1), and through their service name (as specified in the compose-file), for example web. The short name is a network-scoped alias, which means that any container connected to the same network can access the container through this name.

By default, docker-compose creates a network for each compose project (projectname_default) so that all services in the compose project can communicate. Because that network is created for each project individually, two compose project don't share the same network, and their services are isolated from other compose projects.

It's possible, however, to make compose projects (or individual services in a compose project) share the same network.

Example 1 - using a shared network for the whole project