Skip to content

Instantly share code, notes, and snippets.

@groundwater
Last active August 29, 2015 14:08
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save groundwater/c424b921d1272ff76ea9 to your computer and use it in GitHub Desktop.
Save groundwater/c424b921d1272ff76ea9 to your computer and use it in GitHub Desktop.

I've been using CoreOS as an internal Docker PaaS, and have had a few thoughts.

  1. While sub-optimal, there is a need to map in network storage to containers.

    For example, Jenkins stores its configuration on the file system. As CoreOS containers can and should be portable around the cluster, unless you're using some kind of distributed storage your Jenkins configs will disappear periodically.

  2. Almost everything else should be ephemeral. You should replace CoreOS machines with fresh images periodically. Rather than perform maintenance and cleanup of the CoreOS hosts, just replace them. This is not only convenient, but tests failover constantly.

  3. Map in ephemeral storage for apps to use as temporary/scratch disk.

  4. Corollary: databases that do their own replication can use scratch disk instead of network storage

  5. Leverage etcd for service discovery

Docker Ideas

  1. Ports should forward between containers, and containers should always connect to localhost when accessing services. This must work across physical hosts. Ideally connections are tunneled such that the actual outgoing TCP socket is persistent.
  2. The networking layer of docker should be able to chaos/latency monkey its containers
  3. introduce latencies
  4. cause connection failures
  5. partition networks
  6. Native support for mapping in network storage e.g. -v 192.168.0.4/myapp:/storage via NFS or a more robust distributed file system
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment