Original link: http://dockone.io/article/1936
After laying the foundational knowledge points in the previous article, we start the blockchain journey!
The first thing we do is connect the "geth" node to the Ethereum production network, keeping our local blockchain in sync, and opening service ports for other tools - running in containers of course.
"-it" starts the container in interactive mode and sends the container's standard output to our terminal. We can choose to run the process in the background when the container is restarted later, but for now we'll see what happens.
"--name" gives the container the logical name "ethereum", which we can use later to access this instance.
"-p 30303:30303 -p 8545:8545 -p 8546:8546" exposes and maps three ports from inside the container to outside.
"-v /opt/docker/ethereum:/root/.ethereum" mounts the host directory "/opt/docker/ethereum" (where we want to store the blockchain data) to the location "/root/.ethereum". The latter is the default location where "geth" stores all information when started with the root user account.
The ENTRYPOINT command "geth" for this image can be invoked via INSPECTing visualization, just as we would use the tool when running directly on the host. Note that the container command line parameters cannot (easily) be changed later, if a different command line is required, we will need to create a new container. However from Docker's point of view "containers are cheap", so this constraint is not really an issue, especially since the data is not in the container and doesn't need to be re-downloaded. One thing to keep in mind: only one "geth" node can access blockchain data at a time, so it's impossible to have multiple master "geth" nodes running at the same time.
"--ws--rpc" activates the web interface and HTTP RPC interface of "geth" respectively. "--rpcaddr "0.0.0.0" --wsaddr "0.0.0.0" to open these interfaces to all addresses on the network. This is usually a bit dangerous, but we're not running on the host's physical network. More on this later in this section More. Executing the above command should start a new container, invoke the "geth" tool, and start downloading the blockchain data. (Note: you can use the "-fast" option).
The following lines are worth paying attention to:
1. First, the warning prompt "geth" complains that "etherbase" is not defined. "etherbase" is the "default Ethereum address" used to receive ether rewards after successfully mining blocks, executing smart contracts and returning results within the blockchain. This account, is also handy when developing contracts.
2. Next, we see that the blockchain data is written to "/root/.ethereum/chaindata", since we have mounted this directory from our host, we should be able to see the data appearing on the local disk:
3. Finally, the HTTP and Web socket endpoints have been opened and the default IPC (Inter-Process Communication) file handle "/root/.ethereum/geth.ipc" has been created. This would normally be hidden inside the container, but we have mounted the external directory so this file can be used to communicate with this "geth" node.
All that's left is to define a default Ethereum account. Using Docker commands allows executing commands in a running container, so it's easy. Note that these operations do not open a different container, which is attached to the now running container.
Don't forget to write down the Ethereum address and password. In order to be recognized by the "geth" node, the container must be restarted. The new account can be found in our mounted data directory:
在交互式模式下，容器实例可以使用CTRL + C停止。否则，应该调用docker STOP命令。
关于这一点的最后说明：
为了能与以太坊网络同步，主机时间必须精确匹配以太网网络时间。因此，可能需要使用NTP协议与“世界时间”执行同步：
容器相关知识
在当前配置中，我们有一个可以挂载到我们的容器中的以太坊数据目录。这不是因为区块链数据只能在任何情况下由一个进程访问，而是访问可由Ethereum节点用于进程间通信的IPC文件描述符。因此，我们可以在这里继续，而不需要访问网络。然而，为了充分利用我们的完整容器化以太坊节点，了解Docker如何与网络结合可以大大帮助我们为我们未来的用例找到最佳解决方案。众所周知，网络可以是相当复杂的，所以我们在这里只专注于文章内容相关的部分。
默认情况下，Docker容器无法访问主机的网络。如果这样的话，容器化有什么意义呢？作为替代，Docker创建一个单独的虚拟网络，所有容器和主机都可以访问：“docker0”。可以通过显示主机的网络配置查看：
除了我们的本地网络“eth0”（或类似，NB。eth以太网，而不是以太坊），我们看到名为“docker0”的网络。它是一个不同的子网，172.17.42.1是这个网络上的主机IP地址。为了简单，我们将使用由所有容器共享的默认“docker0”网络。但是，知道Docker也允许创建单独的逻辑网络并将它们分配到特定的容器！
获取容器的IP地址不太直接。默认情况下，在轻量级Linux镜像中未安装“ifconfig”。我们可以使用命令“sudo docker exec apt-get -y install .....”安装一切，但是这个需要在每个容器中一次又一次地执行。有一个更容易的解决方案：
对于这个IP必须要清楚的事情是，它会在在容器重新启动时改变。这个对于将IP用于在创建另一个容器作为命令行参数传递时可能是一个问题，我们将在下面看到。
顺便提一句，INSPECT命令允许查看关于容器，系统和IO配置，启动命令行，文件路径和挂载等等的任何信息。
4 、连接JavaScript控制台
接下来，我们想让以太坊主节点与“geth”JavaScript控制台进行交互。这个十分简单…
而棘手的部分是两个容器化的“geth”节点之间的进程间通信。第一个选项是使用安装的数据目录中存在的IPC文件。这是当在同一主机上运行时“geth”节点通信的典型方式。我们需要的是将数据目录安装到第二个节点，在同一个地方，所以“geth”“看到”另一个节点，就好像它只运行一个控制台窗口。两个容器使用相同的IPC描述符进行互连：
替代方案是Web socket或HTTP接口。这需要知道主节点的IP地址，我们知道如何找出.
此方法有一个重要的障碍：我们必须指定主“geth”节点的IP地址作为第二个容器的命令行的一部分。一旦创建，此IP声明不能再更改（除了在配置文件上做手脚），所以这个容器只有在目标容器重新启动和其IP更改之前才有用。
最简单的解决方案是删除此容器，并在每次需要控制台时启动一个新容器。记住 - “容器很便宜”，我们可以用脚本自动化：
5 、运行MIX IDE
现在它将要变得非常有趣。到目前为止，我们使用纯命令行“geth”实例在单独的容器中运行，我们使它们进行通信。运行Ethereum Mix IDE增加了一个新的挑战：使用图形用户界面。
Docker不是真正设计为在容器内运行UI，但是我们可以使用各种技巧来解决。目前有三种方式：
1）将整个X11服务器安装到容器中，并使用一些魔法：），如下所述。这个方式很重，但却是完全“Docker方式”让容器保持隔离。
2）简单地将VNC服务器安装到容器中并远程打开UI。很聪明，但由于性能问题用VNC工作却不是真的那么趣。
3）在正确的地方将Linux主机的X11 IPC（进程间通信）socket装入容器，这是相对优雅的，但却打破了容器之间的隔离，因此可能带来安全和稳定问题。
这个问题解决了，我们需要将Mix IDE转换为容器。由于以太坊团队尚未提供预定义的镜像，我们勇敢地使用“Dockerfile”构建自己的镜像。
第一步是创建一个目录来存储Dockerfile，让我们说“ethereum-mix-ide”。接下来，在内部创建名为“Dockerfile”的文件（文件名是必需的），其内容如下：
最后，在目录中，我们调用Docker命令，逐步执行此脚本，并将最终结果保存到我们的新镜像中。请不要忘记在末尾的“。”，因为它是命令行的一部分。
“Dockerfile”脚本是相当自我解释 。我们的镜像是基于最新的官方UBUNTU镜像。首先，它安装各种工具和Mix IDE。为了能够连接到X服务器，正在运行的进程不能是“root”。因此，脚本创建一个名为“mix”的用户并赋予他sudo权限。最后，“mix-ide”设置为自动启动点。
让我们来验证一下结果：
The image is ready, we'll create a new container, proudly named "ethereumix"
Once built, the container can be restarted at any time:
Alternatively, see warning messages for all betas in interactive mode:
You may have noticed this parameter: "-p 18545:8545". It is indeed a parameter, no typo :) The "geth" master node container already has it's port 8545 bound to the host's port 8545, so we need to choose another place to bind. Since the Mix IDE container initiates the connection to the "geth" master node, the binding location does not matter.
"-v /tmp/.X11-unix:/tmp/.X11-unix" mounts our local X11 server socket to the container, this time using Docker's VOLUME feature, "-e DISPLAY=$DISPLAY" sets $DISPLAY Environment variables have the same value inside the container as we have on the host. This variable specifies the address to be displayed by the X client, which must be set.
Mix IDE does not need access to Blockchain data, but we need to contact the main Ethereum "geth" server node when we want to deploy Smart Contracts on the Blockchain. Again, we need the IP address of the server node:
This time, however, the target address is specified in the UI, and when the server IP changes, the container can be reused without hassle.
The image creation script installs what is needed to use the Mix IDE, but we may need to install additional tools or tweak the container later. As we've seen above, we can execute commands inside the container, which can even be an interactive shell:
