Build a Go-ethereum node based on Docker (upper)

Reference Link: https://github.com/ethereum/go-ethereum/wiki/Running-in-Docker

Reproduced in the original: http://dockone.io/article/1931

The etheric square Go (language) team builds a Docker mirror of a "geth" node as part of its ongoing build chain. We can use these mirrors to quickly run the etheric square node in our local environment. In this article we will build an Ethernet workshop and development environment using Docker.

# # A complete Ethernet square node #
The first test is to download the current Ethereum go-client ("Geth") image and start the client node connected to the Ethernet production network.

Now, let's start a simple node, as described in the Ethereum document. Once the block synchronization begins, use CTRL + C to stop the node. We do not intend to use this container, so we do not need to download the entire chain data now.



Above, we started the Docker container using the Run command. Run takes a mirror called "ethereum/client-go", creates a new container, and launches the entry point (entry points) "/Usr/bin/geth" of the mirror definition.

The following sections need to focus on understanding:
Run always creates a new container. This means that each time we start a container by using run, we end up producing a lot of useless containers. Once the container is created, the correct way to restart it is with the start command. Docker the command line parameter-it-p 30,303:30,303 after the Run command. The "-it" equivalent to "-i-t" represents "interactive" and "terminal equipment (TTY)". Without these instructions, the container will run in the background and will not give us terminal feedback. "-P 30,303:30,303" instructs Docker to expose Port 30303 to hosts and other containers from within the container, with a port number of 30303. The container is an isolated environment and does not expose the port implicitly, and the etheric square client will not be able to touch the outside world and the block chain inside the container. 30303 is the default Ethernet square point-to-point network port. The other parameters that follow the mirror name are used to mirror the commands that are defined as the start point. Not set in this example. 3. Another important part of this test is where the block-chain data is stored. By default, "Geth" uses "$ userhome/. Etherum" As the default data directory. When the container is run internally, it is "root" if not specified: "/root/.ethereum". However, this place is "inside" the container on its "virtual disk". Keeping the data in the container keeps it isolated from the host and other containers, which is not necessarily what we want.
In this example, the node needs to download the entire block chain data. This requires a lot of time, bandwidth, and storage space, and it can become very difficult to share these files among the various containers and hosts.
The shared database is clearly a typical problem when running larger applications, and Docker offers a variety of options in this regard. In previous versions of Docker, people often used so-called "data containers". These are classic and dedicated containers, independent of the application Run-time instances that are designed to store data. The current Docker version replaces the idea with the so-called volumes. In this article, we'll use a different solution: We store the chunk chain and account data on the disk of the host, and mount the directory to the container. This has some advantages for the etheric square, which we will introduce later.

Before continuing, let's take a look at what mirrors we currently have in our installation:

Next, let's list whether our container instance is running. The active container must be specified by adding the '-a ' command:
The inspect command is handy for displaying the entire configuration and condition of the container.

Our current container was previously created using the Run command, and now we will restart the instance with the start command:

"-I" represents the output of the container to our terminal, "D8" represents the container ID, it can also be a mirror name and does not require the full ID to be entered, as long as it is unique.
Alternatively, we can start the container in the background and connect to the terminal later.
Or:
Complete this test and understand the basics described above. In the next chapter we will start the tour of the regional chain.