Turn my original Kubernetes guide into something simple and official.

~/s/g/w/g/aws-ecs master ./setup.sh [85/393]
Creating ECS cluster (weave-ecs-demo-cluster) .. done
Creating Security Group (weave-ecs-demo) .. Done
Creating Key Pair (weave-ecs-demo, file weave-ecs-demo-key.pem) .. done
Creating IAM role (weave-ecs-role) .. done
Creating Launch Configuration (weave-ecs-launch-configuration) .. done
Creating Auto Scaling Group (weave-ecs-demo-group) with 3 instances .. done
Waiting for instances to join the cluster (this may take a few minutes) .. ^C⏎

It appears that it fails to launch Auto Scaling Group:
Launching a new EC2 instance. Status Reason: The security group 'sg-2d396c40' does not exist in VPC 'vpc-d69ff8bb'. Launching EC2 instance failed.

Looks like setup creates a security group that is not attached to any VPC. Also, it appears that setup does not create a dedicated VPC for weave-ecs-demo-cluster.

The current guides assume you are working interactively. It would be good to give one or two examples where you wish to start weave on machine boot, e.g. via systemd or upstart.

This should include where to set DOCKER_HOST

1. Could we get rid of chapter? Maybe use Part? Or just no prefix?
2. Use same yellow box on the overview page as on the chapter pages.

web1 not joining the weave network as expected, in the sample:

sudo docker logs web1

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.0.2. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.0.4. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.1.0.6. Set the 'ServerName' directive globally to suppress this message

In http://weave.works/guides/weave-and-docker-platform/weavenetwork.html we explain "Launching weaveproxy if You are Running OSX", but nowhere do we say that you also need to run weave launch-router.

When trying to run the hello weave and pingme examples from docker commands in proxy, I get the following:

docker exec -i pinger echo "What's up?" | nc pingme.weave.local 4000
nc: getaddrinfo: nodename nor servname provided, or not known

Does the netcat script need to be altered? Or am I doing something wrong here?

Here are the logs, so it looks like dns has found both containers:

docker logs weave
INFO: 2015/08/16 21:59:38.268549 Command line options: map[iface:ethwe ipalloc-range:10.32.0.0/12 name:a2:75:0a:85:17:8b nickname:weave-1 port:6783]
INFO: 2015/08/16 21:59:38.268882 Command line peers: []
INFO: 2015/08/16 21:59:38.269194 Communication between peers is unencrypted.
INFO: 2015/08/16 21:59:38.269384 Our name is a2:75:0a:85:17:8b(weave-1)
INFO: 2015/08/16 21:59:38.270178 [docker] Using Docker API on unix:///var/run/docker.sock: &[BuildTime=Thu Aug 13 02:49:29 UTC 2015 Version=1.8.1 ApiVersion=1.20 GitCommit=d12ea79 GoVersion=go1.4.2 Os=linux Arch=amd64 KernelVersion=4.0.9-boot2docker]
INFO: 2015/08/16 21:59:38.270216 Assuming quorum size of 1
INFO: 2015/08/16 21:59:38.273585 Sniffing traffic on &{10 65535 ethwe 76:08:f3:3b:c7:6e up|broadcast|multicast}
INFO: 2015/08/16 21:59:38.273660 Discovered our MAC 76:08:f3:3b:c7:6e
INFO: 2015/08/16 21:59:38.667028 Discovered local MAC a2:75:0a:85:17:8b
INFO: 2015/08/16 21:59:38.706855 Discovered local MAC 82:58:13:4e:93:58
INFO: 2015/08/16 22:02:16.792037 Discovered local MAC d6:40:52:8f:87:f9
INFO: 2015/08/16 22:02:16.834417 [nameserver a2:75:0a:85:17:8b] adding entry pinger.weave.local. -> 10.32.0.1
INFO: 2015/08/16 22:02:29.251006 Discovered local MAC b6:61:84:4b:e6:2a
INFO: 2015/08/16 22:02:29.289342 [nameserver a2:75:0a:85:17:8b] adding entry pingme.weave.local. -> 10.32.0.2

Editing this guide and running through the sample, Vagrant installs and configures everything, can launch weave, but when running curl in the container, get the following:

curl spring-hello.weave.local
curl: (7) Failed to connect to spring-hello.weave.local port 80: Connection refused

weave version
weave script 1.0.2
weave router 1.0.2
weave DNS 1.0.2
weave exec 1.0.2 

Not sure if this is a known issue or not. Here's the logs from weavedns:

INFO: 2015/08/27 19:01:19.895257 [main] WeaveDNS version 1.0.2
INFO: 2015/08/27 19:01:19.896257 [main] Waiting for mDNS interface ethwe to come up
INFO: 2015/08/27 19:01:19.996720 [main] Interface ethwe is up
INFO: 2015/08/27 19:01:19.996787 [main] Waiting for HTTP interface eth0 to come up
INFO: 2015/08/27 19:01:19.996904 [main] Interface eth0 is up
INFO: 2015/08/27 19:01:19.997115 [zonedb] Using mDNS on &{Index:14 MTU:65535 Name:ethwe HardwareAddr:3e:b5:7d:e8:79:52 Flags:up|broadcast|multicast}
INFO: 2015/08/27 19:01:19.999386 [docker] Using Docker API on unix:///var/run/docker.sock: &[GitCommit=786b29d GoVersion=go1.4.2 Os=linux Arch=amd64 KernelVersion=3.13.0-62-generic Version=1.7.1 ApiVersion=1.19]
INFO: 2015/08/27 19:01:20.000255 [main] HTTP API listening on 10.1.0.2:6785
INFO: 2015/08/27 19:01:20.000372 [dns] Upstream server(s): &{Servers:[10.0.2.3] Search:[] Port:53 Ndots:1 Timeout:5 Attempts:2}
INFO: 2015/08/27 19:01:20.000404 [dns] Cache: 8192 entries
INFO: 2015/08/27 19:01:20.001514 [dns] Listening for DNS on :53 (UDP)
INFO: 2015/08/27 19:01:20.001988 [dns] Listening for DNS on :53 (TCP)
INFO: 2015/08/27 19:01:21.087728 [zonedb] Container bc6e79a71206311701da64f4d9de56c2052b4ddc960e9404bb00ced61634f670 down. Removing records
INFO: 2015/08/27 19:01:21.381134 [zonedb] Container 7d9dde4690ef922ffa3906d8e09839255ba6a71c4a38621ab4a4559735561b29 down. Removing records
INFO: 2015/08/27 19:03:48.446320 [zonedb] Container 27a963ed93495845e36206153b2c26dbc393580587c9a73366999bd34994ee61 down. Removing records
INFO: 2015/08/27 19:03:52.964069 [zonedb] Container f98222addaf2028cb66646c71f89743c705923b0f0cbe6497a0b71273952e4b0 down. Removing records
INFO: 2015/08/27 19:12:17.098385 [http] Adding spring-hello.weave.local -> 10.128.0.2
INFO: 2015/08/27 19:12:36.939981 [http] Adding spring-hello.weave.local -> 10.128.0.3
INFO: 2015/08/27 19:26:07.347041 [http] Adding ubuntu.weave.local -> 10.128.0.4
INFO: 2015/08/27 19:28:38.880625 [zonedb] Container 272dd7a8f74cbb75a17684095dfde0e45c151e3c5f94ed2b59c7d009d3c4b37e down. Removing records
INFO: 2015/08/27 19:28:39.235772 [zonedb] Container 70c109532ff46d5e61bc1cc2ca3c66d1fd6bf434cf53a34e749e74fda669149b down. Removing records
INFO: 2015/08/27 19:28:39.402438 [zonedb] Container 5a408d401e57e53ffc7626fd2a43c0f142af05769118fe910c16cc4a721ebed6 down. Removing records

We should tell users that running ./cleanup.sh after failure in ./setup.sh is safe.

Seems to be a permission issue.

Running $KUBE_RELEASE_TARBALL | tar xzv -C /tmp/ manually on my mac using sudo seems to work.

 Environment=KUBE_RELEASE_TARBALL=https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v1.0.5/kubernetes.tar.gz
      ExecStartPre=/bin/mkdir -p /opt/
      ExecStart=/bin/bash -c "curl --silent --location $KUBE_RELEASE_TARBALL | tar xzv -C /tmp/"
      ExecStart=/bin/tar xzvf /tmp/kubernetes/server/kubernetes-server-linux-amd64.tar.gz -C /opt
      ExecStartPost=/bin/chmod o+rx -R /opt/kubernetes
      ExecStartPost=/bin/ln -s /opt/kubernetes/server/bin/kubectl /opt/bin/

There is a copy of weave in guides/weave-and-docker-platform/scripts, called from at least one of the scripts. I don't know why, and I don't think it should be there.

Similarly guides/mesos-marathon/centos/weave

Hi guys,

I'm wondering if you haven't forgotten to update weave.target:

https://github.com/weaveworks/guides/blob/master/mesos-marathon/centos/weave.target#L6

To remove references to weavedns.service weaveproxy.service which don't exist any longer as far as I can see.

The self-contained, start from scratch nature of the guides makes it quite difficult to see the weave bits. This is especially a problem for experienced users, who know perfectly well how to provision a bunch of machines for testing, and just want to skip to the 'interesting' stuff.

Not sure what to do about that. Perhaps have a very clear delineation in each guide between the infrastructure setup, and weave bits. Which might be tricky in some cases.

I worked through the guide, and jotted down some notes:

The script scripts/1-machine-create.sh repeats 4 lines, which is a potential source of error.

Next launch Weave onto each of the virtual machines.
On weave-1 run:

It is not made very clear how you specifically go about doing this. I think you are supposed to do eval "$(docker-machine env weave-1)" then run weave.

[note: the split between weave launch-router and weave launch-proxy could be avoided if the script split off the tls arguments, or weaver ignored them.]

weave-1 is the bootstrap node, and so its target should be 0. Only weave-2 and weave-3 need to have --init-peer-count set to 3 at launch

This distinction is unnecessary, and indeed is not followed by the script provided.

and finally, set the weave environment variable for weave-1
eval $(weave env)

Setting this is a bad idea at this point, since on the next line we need to point the docker CLI at weave-2.

Specify the TLS settings if asked:

It is unnecessary to re-set $tlsargs, since it doesn't vary from machine to machine.

Check that they are in a Swarm:

The guide doesn't say which part of the output indicates a Swarm, or what to do if you see something different.

like we did in the two previous chapters.

we are in chapter 2 right now; how come there are two previous chapters?

Before we tear down these two running containers,

this part does not go as described because the nc has exited upon connection closure, hence the "pingme" container does not appear in the list.

I have just made a few quite simple changes to the Mesos guide that make it run on Ubuntu instead of CentOS.

It's not hard to arrange scripts and Vagrantfile to handle small differences between distros and save users some time, especially that it's now a given most distros use systemd and it's all about Docker.

However, It's not feasible to maintain a copies of text, so I think we can have a simple selector button.

In the guide, one can write markdown like this:

~~~ bash
[root@mesos-01 vagrant]# docker run -ti centos:7
[root@7844aae5d94d /]# curl outyet:8080
~~~
{: .for-centos }

~~~ bash
[root@mesos-01 vagrant]# docker run -ti ubuntu:15.04
[root@7844aae5d94d /]# apt-get install curl
...
[root@7844aae5d94d /]# curl outyet:8080
~~~
{: .for-ubuntu }

And with a tiny bit of JavaScript we can flip around instructions for the distro user has picked.

We should probably add a Mac guide to http://weave.works/guides/weave-docker-index.html, which currently only lists CentOS, CoreOS and Ubuntu.

in http://weave.works/guides/weave-and-docker-platform/weavenetwork.html

Reported on IRC

I have no idea how docker-machine decides what the listen on, but evidently OSX isn't the only platform on which it will listen with TLS only.

This issue will go away with weave 1.2 since we auto-configure TLS there. Meanwhile I suggest we update the guide, perhaps with a note on the weave launch saying "If this fails with ... then follow the 'Launching Weave with TLS' instructions instead", and rename the OSX instructions to "Launching Weave with TLS".

See weaveworks/weave#1392

Product names vs. services or libraries are inconsistent, and should be standardized via the naming conventions put in place.

• use the outyet app from Mesosphere guides
• run interactive test container outside of Marathon and show DNS working etc
• add conclusion
• add pointers to provisioning lines in Vagrantfile
• include two of the diagrams that had already been created
• add a few screenshots

In http://weave.works/guides/weave-and-docker-platform/chapter2/machine-with-weave-proxy.html we see --with-ipam, which is not a proxy option.

Reported on IRC by 'tofuboy'

http://weave.works/guides/weave-and-docker-platform/weavenetwork.html

Check to see that the proxy is running properly: docker logs weaveproxy

No point doing that. We want to know whether everything is running properly. weave status does that; it includes a proxy section if the proxy is running.

NB: the above appears in both the "Let's go" and osx sections.

Both weavedns and weaveproxy services can be started and stopped independently,

Not so. The router and proxy can be started independently. But frankly I don't see the point of mentioning that here.

View and copy the settings, if necessary: echo $tlsargs

Why would one want to do that? I'd drop this step; keep it simple.

docker run -e 'affinity:container!=pingme' ...

This merits explanation!

pinger:/# ping -c3 pingme.weave.local

Here and elsewhere, the .weave.local should not be necessary.

Sometimes you end up in 'weaveworks-guides', sometimes in 'guides', sometimes in 'weaveworks/guides'.

At least in weave-and-docker-platform; whoever fixes this should scan the whole repo.

Note that if you have done a 'git clone' following one set of instructions, and then we change the location, the old files stick around to trip you up later.

See weaveworks/weave#1066 - a similar change should be made to the guides.

There are a lot of uses of sudo in the guides, and at weaveworks/weave#1186 @rade suggests we should never do that.

As noted in that issue, the sequence of commands where you start the weave proxy using sudo and then run docker commands without sudo will stop working in 1.1, and we can't fix it by adding sudo to the later docker commands.

Example instance: https://github.com/weaveworks/guides/blob/master/nginx-ubuntu-simple/README.md#starting-our-example

Someone could easily claim this environment variable for anything of their own and get weird errors from weave script.

We must do it as soon as we can.

I would split this script into 3 or 4 parts to make it easier to debug when something fails.

For example, a script would be created for each step listed below, which we can explain in the Guide:

1. provision VMs. with CoreOS cluster
2. launch weave
3. Deploy Kubernetes
4. Deploy app

One similar to Mesos.

http://weave.works/guides/weave-docker-centos-simple.html

URL: ["https://atlas.hashicorp.com/chef/centos-7.0"] Error: The requested URL returned error: 404 Not Found

per email:

But when I run “vagrant up” I’ve got this error:
Bringing machine 'weave-gs-01' up with 'virtualbox' provider... Bringing machine 'weave-gs-02' up with 'virtualbox' provider... ==> weave-gs-01: Box 'chef/centos-7.0' could not be found. Attempting to find and install... weave-gs-01: Box Provider: virtualbox weave-gs-01: Box Version: >= 0 The box 'chef/centos-7.0' could not be found or could not be accessed in the remote catalog. If this is a private box on HashiCorp's Atlas, please verify you're logged in viavagrant login. Also, please double-check the name. The expanded URL and error message are shown below:

It seems to fail because the image “chef/centos-7.0” no longer exist, I have tested with “wlc/centos-7.0” and it worked but I’ve got other error related to Virtual Box Guest Additions and I’m stuck on it. (using Vagrant 1.7.4 and Virtual Box 5.0.2).

I deleted all VMs and re-booted my system and ran vagrant up SSH'ed onto kube-01 and it showed the following:

CoreOS stable (723.3.0)
Update Strategy: No Reboots
Failed Units: 2
  weave.service
  weaveproxy.service 

So, then I ran:

weave launch

FATA[0000] Error response from daemon: Cannot start container 18e96982e04f4baf07f78bc276282946fb42efd7c470bac09ab900872683c064: [8] System error: write /sys/fs/cgroup/cpuset/system.slice/docker-18e96982e04f4baf07f78bc276282946fb42efd7c470bac09ab900872683c064.scope/cgroup.procs: no space left on device 

Once weaveworks/weave#1414 is ready to be released, we should simplify the usage for OSX, and write a short OSX getting started guide.

Most of the guides pre-date 1.0 and thus are inconsistent with the main docs.

In particular they should:

• always launch weave with

weave launch && weave launch-dns && weave launch-proxy
eval $(weave proxy-env)

(modulo variations to launch args)

• always start containers with docker, through the proxy, never with weave run
• always take advantage of ipam and naming; there should be no IP addresses in sight
• always let hostnames derive from container names; never specify hostnames with -h
• always address containers by their short name instead of fqdn
• always rely on the default IPAM subnet; never configure IPAM with an explicit subnet

...unless there are very specific reason to do something different.

There are probably more. Take a look at the main docs to get a feel for how weave is meant to be used to these days.

Make him official, which is likely to imply some refactoring.

See kramdown docs.

The script has stopped working and fails to see that the response from aws contains "<Response [200]>" in the response.

The cluster check "ACTIVE/INACTIVE" fails..Also the "SECURity_GROUP" fails and SUBNET fails !!

These variables are improperly set.

Some stutter in http://weave.works/guides/weave-and-docker-platform/using-weave-with-machine-and-swarm.html:

and finally, set the weave environment variable for weave-1

eval "$(weave env)"

Set the weave env for weave-1

eval "$(weave env)"

A @rade pointed out in #52 (comment):

Is there a way to setup weave+k8s that doesn't involve us having copies of 400+ lines of config, the vast majority of which has nothing to do with weave?

I believe we can should first provide a general single-host walk through guide that would explain what needs to be done, so a user can derive their version for any environment.

I tried various things, I just didn't manage to get anything working...

https://microblog.pierre-o.fr/2015/docker-global-hackday---weave-fail

I had everything uptodate (docker, machine, compose). I used digitalocean as provider. My machine is ubuntu.

It is hard to tell what is the issue as there were many. Just try it again, and I think you'll see. I'd be really happy to make it working!

Tell me how we could manage together :)

Best, and thanks for your work :)

https://github.com/weaveworks/guides/tree/master/weave-and-docker-platform/scripts

script needs to be adapted to weave launch

Should use it in platform guide.

Reported by a user...

I was trying to test http://weave.works/guides/weave-docker-centos-simple.html

But when I run “vagrant up” I’ve got this error:

Bringing machine 'weave-gs-01' up with 'virtualbox' provider...
Bringing machine 'weave-gs-02' up with 'virtualbox' provider...
==> weave-gs-01: Box 'chef/centos-7.0' could not be found. Attempting to find and install...
   weave-gs-01: Box Provider: virtualbox
   weave-gs-01: Box Version: >= 0
The box 'chef/centos-7.0' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:
URL: ["https://atlas.hashicorp.com/chef/centos-7.0"]
Error: The requested URL returned error: 404 Not Found

It seems to fail because the image “chef/centos-7.0” no longer exist, I have tested with “wlc/centos-7.0” and it worked but I’ve got other error related to Virtual Box Guest Additions and I’m stuck on it. (using Vagrant 1.7.4 and Virtual Box 5.0.2).

Other guides have the same problem with the non existing 'chef/centos-7.0' image.

Ubuntu and CentOS guides need updating. Ubuntu one should probably be the easiest to do first, the CentOS one should mirror it 95%. We should eventually proceed to merge the two in towards #38.

User has to have full access to go through the ECS guide, as it does a whole lot of things.

Per weaveworks/weave#1414 (comment)...

http://weave.works/guides/weave-and-docker-platform/weavenetwork.html and http://weave.works/guides/weave-and-docker-platform/using-weave-with-machine-and-swarm.html and https://github.com/weaveworks/guides/blob/6db6ee1e11d7e37d30506095620cfccb03dbbefa/weave-and-docker-platform/scripts/2-weave-launch.sh need updating - they all feature the TLS hack, the need for which has been eliminated (in the upcoming weave 1.2). Which also means the router and proxy can now be launched together with weave launch.

Hi,

I see the CentOS Mesos/Marathon guide provides its own systemd unit files. I find them quite valuable but I'd feel more confident if they were made official somehow. Could they be made part of the main weave repository?

Docker provides similar unit files too: https://github.com/docker/docker/tree/master/contrib/init/systemd

Thanks,

@ljsommer said in #6 (comment)

I want to see diagrams of use cases with dependencies and commands. I want to see these because that's what it takes to design an infrastructure for production.

Currently we have shell scripts, but trying to introduce VPC into the mix quickly becomes a pain. We can also make use of resource groups etc. With CloudFormation it would be much easier to do anything and we forget error handling and cleanup from there onwards.