pipework let's assign static IP to docker container simple.

Docker's recent advances have made it the darling of startups and innovators throughout the IT world, but one pain point causes admins and developers alike to bite their nails: networking. Managing the interaction between Docker containers and networks has always been fraught with complications.

To some intrepid developers, that's a challenge and not an obstacle. Here are five of the most significant projects currently in the works to solve Docker networking issues, with the possibility that one or more of them might become part of Docker itself.

Weave

Created by Zett.io, Weave "makes the network fit the application, not the other way round," as the company CEO puts it. With Weave, Docker containers are all part of a virtual network switch no matter where they're running. Services can be selectively exposed across the network to the outside world through firewalls and using encryption for wide-area connections.

The gist: Possibly the best place to start, since it solves most of the really immediate problems in a straightforward way. But other solutions might offer more depending on your ambitions.

Kubernetes

Google's big first leap into the Docker world was an orchestration project, a way to tackle node balancing and many other valuable orchestration-related functions with Docker containers. It also provides, rather deliberately, some solutions to Docker's networking issues, though it goes only so far in that realm.

The gist: A good start as-is, but heavy lifting is still required to get the most out of it.

CoreOS, Flannel

Given that CoreOS is a project meant to architect an entire Linux distribution around Docker, it makes sense for networking to be part of the package. A project named Flannel (previously Rudder) is at the heart of how CoreOS manages container networking, connecting all the containers in a cluster via their own private mesh network. Presto, no more clumsy port mapping!

The gist: Best with CoreOS; requires Kubernetes at least.

Pipework

A solution devised by one of Docker's engineers, Pipework allows containers to be connected "in arbitrarily complex scenarios." It was devised as an interim solution and will probably end up as one.

The gist: It's best as a curiosity or a technology concept in the long run; as its creator admits, "Docker will [eventually] allow complex scenarios, and Pipework should become obsolete."

SocketPlane

Right now SocketPlane's work consists of little more than a press announcement "to bring software defined networking to Docker." The idea is to use the same devops tools used to deploy Docker to manage virtualized networks for containers, and build what amounts to an OpenDaylight/Open vSwitch fabric for Docker. It all sounds promising, but we won't be able to see any product until at least the first quarter of 2015.

The gist: Don't hold your breath until it's out.

   else
        case "$IFNAME" in
        br*)
            IFTYPE=bridge
            BRTYPE=linux
            ;;
        ovs*)
            if ! $(which ovs-vsctl >/dev/null) 
            then
                echo "Need OVS installed on the system to create an ovs bridge"
            exit 1
            fi
            IFTYPE=bridge
            BRTYPE=openvswitch
            ;;
        *)
            echo "I do not know how to setup interface $IFNAME."
            exit 1
            ;;
        esac

# Give our ARP neighbors a nudge about the new interface
if which arping > /dev/null 2>&1
then
    IPADDR=$(echo $IPADDR | cut -d/ -f1)
    ip netns exec $NSPID arping -c 1 -A -I $CONTAINER_IFNAME $IPADDR > /dev/null 2>&1 || true
else
    echo "Warning: arping not found; interface may not be immediately reachable"
fi

# Remove NSPID to avoid `ip netns` catch it.
[ -f /var/run/netns/$NSPID ] && rm -f /var/run/netns/$NSPID
exit 0

[root@localhost ~]# ovs-vsctl add-br ovs0
[root@localhost ~]# ip link set ovs0 up
[root@localhost ~]# ip addr add 172.0.42.1/24 dev ovs0
[root@localhost ~]# ovs-vsctl show
f345b7e3-fcb0-4ef3-8295-36d3ef69ceef
    Bridge "ovs0"
        Port "ovs0"
            Interface "ovs0"
                type: internal
    ovs_version: "2.3.0"

[root@localhost ~]# docker run --rm -t -i --net=none --name=testpipework centos:centos7 /bin/bash
[root@7eb07fe4bbf8 /]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

[root@localhost ~]# ./pipework.sh ovs0 testpipework 172.0.42.2/24

[root@7eb07fe4bbf8 /]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
56: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 3e:15:74:c0:64:21 brd ff:ff:ff:ff:ff:ff
网络已正常
[root@7eb07fe4bbf8 /]# ping 172.0.42.1
PING 172.0.42.1 (172.0.42.1) 56(84) bytes of data.
64 bytes from 172.0.42.1: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 172.0.42.1: icmp_seq=2 ttl=64 time=0.055 ms
^C
--- 172.0.42.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.055/0.212/0.369/0.157 ms
路由也加了
[root@7eb07fe4bbf8 /]# ip route
172.0.42.0/24 dev eth1  proto kernel  scope link  src 172.0.42.2