Docker - Revision history

Rasimsen: /* Automating Docker Builds With Gradle */

2020-05-22T12:41:58Z

‎Automating Docker Builds With Gradle

Rasimsen: /* Automating Docker Builds With Gradle */

2020-05-22T12:41:30Z

‎Automating Docker Builds With Gradle

Rasimsen: /* Automating Docker Builds With Gradle */

2020-05-22T12:40:37Z

‎Automating Docker Builds With Gradle

Rasimsen: /* Automating Docker Builds With Gradle */

2020-05-22T12:40:02Z

‎Automating Docker Builds With Gradle

Rasimsen: /* Docker Network */

2020-05-22T12:26:55Z

‎Docker Network

Show changes

Rasimsen at 12:12, 22 May 2020

2020-05-22T12:12:48Z

Rasimsen: /* Automating Docker Builds With Gradle */

2020-05-07T08:37:03Z

‎Automating Docker Builds With Gradle

Rasimsen at 08:32, 7 May 2020

2020-05-07T08:32:15Z

Rasimsen at 08:28, 7 May 2020

2020-05-07T08:28:04Z

Rasimsen at 08:27, 7 May 2020

2020-05-07T08:27:28Z

@@ Line 19: / Line 19: @@
 Create Dockerfile task	|                           |            ✓
 Build image task        |            ✓              |            ✓
-Push image task	        |            ✓    	    |            ✓
+Push image task	        |            ✓              |            ✓
 Tag image task          |            ✓
 Run container task      |            ✓

@@ Line 18: / Line 18: @@
 Feature Description	      Palantir Docker Plugin	   Bmuschko Docker Plugin
 Create Dockerfile task	|                           |            ✓
-Build image task	|            ✓              |            ✓
+Build image task        |            ✓              |            ✓
 Push image task	        |            ✓    	    |            ✓
-Tag image task	        |            ✓
+Tag image task          |            ✓
-Run container task	|            ✓
+Run container task      |            ✓
-Stop container task	|            ✓
+Stop container task     |            ✓
-Remove container task	|            ✓
+Remove container task   |            ✓
 Summary Palantir        |More tasks with more functionality available. Less configuration required. Uses provided Dockerfile, which cannot be generated automatically

@@ Line 18: / Line 18: @@
 Feature Description	      Palantir Docker Plugin	   Bmuschko Docker Plugin
 Create Dockerfile task	|                           |            ✓
-Build image task	      |            ✓              |            ✓
+Build image task	|            ✓              |            ✓
-Push image task	        |            ✓    	        |            ✓
+Push image task	        |            ✓    	    |            ✓
 Tag image task	        |            ✓
-Run container task	    |            ✓
+Run container task	|            ✓
-Stop container task	    |            ✓
+Stop container task	|            ✓
-Remove container task	  |            ✓
+Remove container task	|            ✓
 Summary Palantir        |More tasks with more functionality available. Less configuration required. Uses provided Dockerfile, which cannot be generated automatically

← Older revision		Revision as of 12:40, 22 May 2020
Line 3:		Line 3:

	We’re all using Docker containers these days to do all sorts of great stuff, but it’s not always obvious how best to automate the building of images and embed good repeatable processes into our projects.		We’re all using Docker containers these days to do all sorts of great stuff, but it’s not always obvious how best to automate the building of images and embed good repeatable processes into our projects.
		+
		+
		+	When it comes to Docker plugins there are two main players right now, the Palantir Docker Plugin and the Bmuschko Docker Plugin. Technically, they are best described as suites of plugins as there are separate plugins providing specific fine grained functionality.
		+
		+	I generally use the Palantir Docker Plugin as it’s slightly less opinionated in that it let’s you configure your own Dockerfile. This is the plugin I’ll be using in this article. The Bmuschko Docker Plugin, on the other hand, generates the Dockerfile for you or allows you to configure it’s instructions in your build.gradle.
		+
		+	Palantir Docker Plugin : https://plugins.gradle.org/search?term=com.palantir.docker
		+
		+	Bmuschko Docker Plugin: https://plugins.gradle.org/search?term=com.bmuschko.docker
		+
		+	Good resource : https://tomgregory.com/automating-docker-builds-with-gradle/
		+
		+	<source>
		+	Feature Description Palantir Docker Plugin Bmuschko Docker Plugin
		+	Create Dockerfile task \| \| ✓
		+	Build image task \| ✓ \| ✓
		+	Push image task \| ✓ \| ✓
		+	Tag image task \| ✓
		+	Run container task \| ✓
		+	Stop container task \| ✓
		+	Remove container task \| ✓
		+
		+	Summary Palantir \|More tasks with more functionality available. Less configuration required. Uses provided Dockerfile, which cannot be generated automatically
		+	Summary Palantir \|Less tasks available, but you can implement one of the provided custom task types. Configuration is more opinionated. e.g. you can build an image for a Spring Boot project, without having to define the Dockerfile
		+
		+	</source>

	=Get started with Docker for Mac=		=Get started with Docker for Mac=

← Older revision		Revision as of 12:12, 22 May 2020
Line 199:		Line 199:
	Below are some commonly used Docker commands:		Below are some commonly used Docker commands:
	https://d1jnx9ba8s6j9r.cloudfront.net/blog/wp-content/uploads/2016/12/Docker-Commands-Docker-Interview-Questions-Edureka-1.png		https://d1jnx9ba8s6j9r.cloudfront.net/blog/wp-content/uploads/2016/12/Docker-Commands-Docker-Interview-Questions-Edureka-1.png
		+
		+	==Docker Network==
		+
		+
		+	===Networking with standalone containers===
		+
		+	Simply if you want to run two or more container in a same network, you might do it like below:
		+
		+	<source>
		+	$ docker network create --subnet=172.18.0.0/16 dynamodb-local-net
		+	</source>
		+
		+	<source>
		+	$ docker run -dit --name alpine1 --network alpine-net alpine ash
		+	</source>
		+
		+	<source>
		+	$ docker network inspect dynamodb-local-net //who is connected this network
		+	</source>
		+
		+	====Use the default bridge network====
		+	In this example, you start two different alpine containers on the same Docker host and do some tests to understand how they communicate with each other. You need to have Docker installed and running.
		+
		+	*Open a terminal window. List current networks before you do anything else. Here’s what you should see if you’ve never added a network or initialized a swarm on this Docker daemon. You may see different networks, but you should at least see these (the network IDs will be different):
		+
		+	<source>
		+	$ docker network ls
		+
		+	NETWORK ID NAME DRIVER SCOPE
		+	17e324f45964 bridge bridge local
		+	6ed54d316334 host host local
		+	7092879f2cc8 none null local
		+	</source>
		+
		+	The default bridge network is listed, along with host and none. The latter two are not fully-fledged networks, but are used to start a container connected directly to the Docker daemon host’s networking stack, or to start a container with no network devices. This tutorial will connect two containers to the bridge network.
		+
		+	* Start two alpine containers running ash, which is Alpine’s default shell rather than bash. The -dit flags mean to start the container detached (in the background), interactive (with the ability to type into it), and with a TTY (so you can see the input and output). Since you are starting it detached, you won’t be connected to the container right away. Instead, the container’s ID will be printed. Because you have not specified any --network flags, the containers connect to the default bridge network.
		+
		+	<source>
		+	$ docker run -dit --name alpine1 alpine ash
		+
		+	$ docker run -dit --name alpine2 alpine ash
		+	</source>
		+
		+	Check that both containers are actually started:
		+
		+	<source>
		+	$ docker container ls
		+
		+	CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
		+	602dbf1edc81 alpine "ash" 4 seconds ago Up 3 seconds alpine2
		+	da33b7aa74b0 alpine "ash" 17 seconds ago Up 16 seconds alpine1
		+	</source>
		+
		+	Inspect the bridge network to see what containers are connected to it.
		+
		+	<source>
		+	$ docker network inspect bridge
		+	</source>
		+	Near the top, information about the bridge network is listed, including the IP address of the gateway between the Docker host and the bridge network (172.17.0.1). Under the Containers key, each connected container is listed, along with information about its IP address (172.17.0.2 for alpine1 and 172.17.0.3 for alpine2).
		+
		+	The containers are running in the background. Use the docker attach command to connect to alpine1.
		+
		+	<source>
		+	$ docker attach alpine1
		+
		+	/ # <------------------ command line for the container, you can ping internet or other container etc..
		+	</source>
		+
		+	The prompt changes to # to indicate that you are the root user within the container. Use the ip addr show command to show the network interfaces for alpine1 as they look from within the container:
		+
		+	<source>
		+	# ip addr show
		+	</source>
		+
		+	The first interface is the loopback device. Ignore it for now. Notice that the second interface has the IP address 172.17.0.2, which is the same address shown for alpine1 in the previous step.
		+
		+	* From within alpine1, make sure you can connect to the internet by pinging google.com. The -c 2 flag limits the command to two ping attempts.
		+
		+	<source>
		+	# ping -c 2 google.com
		+
		+	PING google.com (172.217.3.174): 56 data bytes
		+	64 bytes from 172.217.3.174: seq=0 ttl=41 time=9.841 ms
		+	64 bytes from 172.217.3.174: seq=1 ttl=41 time=9.897 ms
		+
		+	--- google.com ping statistics ---
		+	2 packets transmitted, 2 packets received, 0% packet loss
		+	round-trip min/avg/max = 9.841/9.869/9.897 ms
		+	</source>
		+
		+	* Now try to ping the second container. First, ping it by its IP address, 172.17.0.3:
		+	<source>
		+	# ping -c 2 172.17.0.3
		+	</source>
		+
		+	This succeeds. Next, try pinging the alpine2 container by container name. This will fail.
		+
		+	<source>
		+	# ping -c 2 alpine2
		+	ping: bad address 'alpine2'
		+	</source>
		+
		+	* Detach from alpine1 without stopping it by using the detach sequence, CTRL + p CTRL + q (hold down CTRL and type p followed by q). If you wish, attach to alpine2 and repeat steps 4, 5, and 6 there, substituting alpine1 for alpine2.
		+
		+	* Stop and remove both containers.
		+
		+	<source>
		+	$ docker container stop alpine1 alpine2
		+	$ docker container rm alpine1 alpine2
		+	</source>
		+
		+	<source>
		+
		+	****** Remember, the default bridge network is not recommended for production.
		+
		+	</source>
		+
		+	docker network document : https://docs.docker.com/network/network-tutorial-standalone/

← Older revision		Revision as of 08:37, 7 May 2020
Line 1:		Line 1:

	=[[Automating Docker Builds With Gradle]]=		=[[Automating Docker Builds With Gradle]]=
		+
		+	We’re all using Docker containers these days to do all sorts of great stuff, but it’s not always obvious how best to automate the building of images and embed good repeatable processes into our projects.

	=Get started with Docker for Mac=		=Get started with Docker for Mac=

← Older revision		Revision as of 08:32, 7 May 2020
Line 1:		Line 1:

−	=[[Docker Gradle ~~Plugin~~]]=	+	=[[Automating Docker Builds With Gradle]]=

	=Get started with Docker for Mac=		=Get started with Docker for Mac=

← Older revision		Revision as of 08:28, 7 May 2020
Line 1:		Line 1:

−	=[Docker Gradle Plugin]=	+	=[[Docker Gradle Plugin]]=

	=Get started with Docker for Mac=		=Get started with Docker for Mac=

← Older revision		Revision as of 08:27, 7 May 2020
Line 1:		Line 1:
		+
		+	=[Docker Gradle Plugin]=
		+
	=Get started with Docker for Mac=		=Get started with Docker for Mac=
	[[Docker Notes]]		[[Docker Notes]]