deleted file mode 100644

@@ -1,41 +0,0 @@

-# Install and Configure DCOS CLI for Mesos

-

-To install the DCOS CLI:

-Install virtualenv. The Python tool virtualenv is used to manage the DCOS CLI’s environment.

-

-```

-sudo pip install virtualenv

-```

-

-Tip: On some older Python versions, ignore any ‘Insecure Platform’ warnings. For more information, see https://virtualenv.pypa.io/en/latest/installation.html. From the command line, create a new directory named dcos and navigate into it.

-

-```

-$ mkdir dcos

-$ cd dcos

-$ curl -O https://downloads.mesosphere.io/dcos-cli/install.sh

-```

-

-Run the DCOS CLI install script, where <hosturl> is the hostname of your master node prefixed with http://:

-```

-$ bash install.sh <install_dir> <mesos-master-host>

-```

-

-For example, if the hostname of your Mesos master node is mesos-master.example.com:

-

-```

-$ bash install.sh . http://mesos-master.example.com

-```

-

-Follow the on-screen DCOS CLI instructions and enter the Mesosphere verification code. You can ignore any Python ‘Insecure Platform’ warnings.

-

-```

-Confirm whether you want to add DCOS to your system PATH:

-$ Modify your bash profile to add DCOS to your PATH? [yes/no]

-```

-

-Since DCOS CLI is used for DCOS cluster, reconfigure Marathon and Mesos masters URLs with the following commands:

-

-```

-dcos config set core.mesos_master_url http://<mesos-master-host>:5050

-dcos config set marathon.url http://<marathon-host>:8080

-```

deleted file mode 100644

@@ -1,59 +0,0 @@

-# Install and Configure Marathon for Mesos Cluster on PhotonOS

-

-In this How-To I am going to explain how to install and configure Marathon for Mesos cluster. All the following steps should be done on each Mesos master.

-

-First, download Marathon:

-

-```

-root@pt-mesos-master2 [ ~ ]# mkdir -p  /opt/mesosphere/marathon/ && cd /opt/mesosphere/marathon/

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]#  curl -O http://downloads.mesosphere.com/marathon/v0.13.0/marathon-0.13.0.tgz

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# tar -xf marathon-0.13.0.tgz

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# mv marathon-0.13.0 marathon

-```

-

-Create a configuration for Marathon:

-

-```

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# ls -l /etc/marathon/conf/

-total 8

--rw-r--r-- 1 root root 68 Dec 24 14:33 master

--rw-r--r-- 1 root root 71 Dec 24 14:33 zk

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# cat /etc/marathon/conf/*

-zk://192.168.0.2:2181,192.168.0.1:2181,192.168.0.3:2181/mesos

-zk://192.168.0.2:2181,192.168.0.1:2181,192.168.0.3:2181/marathon

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# cat /etc/systemd/system/marathon.service

-[Unit]

-Description=Marathon

-After=network.target

-Wants=network.target

- 

-[Service]

-Environment="JAVA_HOME=/opt/OpenJDK-1.8.0.51-bin"

-ExecStart=/opt/mesosphere/marathon/bin/start \

-    --master zk://192.168.0.2:2181,192.168.0.1:2181,192.168.0.3:2181/mesos \

-    --zk zk://192.168.0.2:2181,192.168.0.1:2181,192.168.0.3:2181/marathon

-Restart=always

-RestartSec=20

- 

-[Install]

-WantedBy=multi-user.target

-```

-

-Finally, we need to change the Marathon startup script, since PhotonOS do not use the standard JRE. 

-

-Make sure you add JAVA_HOME to Java path:

-

-```

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# tail -n3 /opt/mesosphere/marathon/bin/start

-# Start Marathon

-marathon_jar=$(find "$FRAMEWORK_HOME"/target -name 'marathon-assembly-*.jar' | sort | tail -1)

-exec "${JAVA_HOME}/bin/java" "${java_args[@]}" -jar "$marathon_jar" "${app_args[@]}"

-```

-

-Now we can start the Marthon service:

-```

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# systemctl start marathon

-root@pt-mesos-master2 [ /opt/mesosphere/marathon ]# ps -ef | grep marathon

-root     15821     1 99 17:14 ?        00:00:08 /opt/OpenJDK-1.8.0.51-bin/bin/java -jar /opt/mesosphere/marathon/bin/../target/scala-2.11/marathon-assembly-0.13.0.jar --master zk://192.168.0.2:2181,192.168.0.1:2181,192.168.0.3:2181/mesos --zk zk://192.168.0.2:2181,192.168.0.1:2181,192.168.0.3:2181/marathon

-root     15854 14692  0 17:14 pts/0    00:00:00 grep --color=auto marathon

-```

\ No newline at end of file

deleted file mode 100644

@@ -1,158 +0,0 @@

-# Install and Configure Mesos DNS on a Mesos Cluster

-

-## Overview 

-

-Before you read this How-To, please read: [Install and Configure a Production-Ready Mesos Cluster on PhotonOS](Install-and-Configure-a-Production-Ready-Mesos-Cluster-on-Photon-OS.md), [Install and Configure Marathon for Mesos Cluster on PhotonOS](Install-and-Configure-Marathon-for-Mesos-Cluster-on-PhotonOS.md) and [Install and Configure DCOS CLI for Mesos](Install-and-Configure-DCOS-CLI-for-Mesos.md).

-

-After you have fully installed and configured the Mesos cluster, you can execute jobs on it. However, if you want a service discovery and load balancing capabilities you will need to use Mesos-DNS and Haproxy. In this How-To I will explain how to install and configure Mesos-DNS for your Mesos cluster.

-Mesos-DNS supports service discovery in Apache Mesos clusters. It allows applications and services running on Mesos to find each other through the domain name system (DNS), similarly to how services discover each other throughout the Internet. Applications launched by Marathon are assigned names like search.marathon.mesos. Mesos-DNS translates these names to the IP address and port on the machine currently running each application. To connect to an application in the Mesos datacenter, all you need to know is its name. Every time a connection is initiated, the DNS translation will point to the right machine in the datacenter.

-

-![Architecture](images/architecture.png)

-

-## Installation

-

-I will explain how to configure Mesos-DNS docker and run it through Marathon. I will show you how to create a configuration file for a mesos-dns-docker container and how to run it via Marathon.

-

-```

-root@pt-mesos-node1 [ ~ ]# cat /etc/mesos-dns/config.json

-{

-  "zk": "zk://192.168.0.1:2181,192.168.0.2:2181,192.168.0.3:2181/mesos",

-  "masters": ["192.168.0.1:5050", "192.168.0.2:5050", "192.168.0.3:5050"],

-  "refreshSeconds": 60,

-  "ttl": 60,

-  "domain": "mesos",

-  "port": 53,

-  "resolvers": ["8.8.8.8"],

-  "timeout": 5,

-  "httpon": true,

-  "dnson": true,

-  "httpport": 8123,

-  "externalon": true,

-  "SOAMname": "ns1.mesos",

-  "SOARname": "root.ns1.mesos",

-  "SOARefresh": 60,

-  "SOARetry":   600,

-  "SOAExpire":  86400,

-  "SOAMinttl": 60

-}

-```

-

-### Create Application Run File

-

-Next step is to create a json file and run the service from Marathon for HA. It is possible to run the service via API or via DCOS CLI.

-

-```

-client:~/mesos/jobs$ cat mesos-dns-docker.json

-{

-    "args": [

-        "/mesos-dns",

-        "-config=/config.json"

-    ],

-    "container": {

-        "docker": {

-            "image": "mesosphere/mesos-dns",

-            "network": "HOST"

-        },

-        "type": "DOCKER",

-        "volumes": [

-            {

-                "containerPath": "/config.json",

-                "hostPath": "/etc/mesos-dns/config.json",

-                "mode": "RO"

-            }

-        ]

-    },

-    "cpus": 0.2,

-    "id": "mesos-dns-docker",

-    "instances": 3,

-    "constraints": [["hostname", "CLUSTER", "pt-mesos-node2.example.com"]]

-}

-```

-

-Now we can see in the Marthon and Mesos UI that we launched the application.

-

-

-### Setup Resolvers and Testing

-

-To allow Mesos tasks to use Mesos-DNS as the primary DNS server, you must edit the file */etc/resolv.conf* in every slave and add a new nameserver. For instance, if *mesos-dns* runs on the server with IP address *192.168.0.5* at the beginning of */etc/resolv.conf* on every slave.

-

-```

-root@pt-mesos-node2 [ ~/mesos-dns ]# cat /etc/resolv.conf

-# This file is managed by systemd-resolved(8). Do not edit.

-#

-# Third party programs must not access this file directly, but

-#only through the symlink at /etc/resolv.conf. To manage

-# resolv.conf(5) in a different way, replace the symlink by a

-# static file or a different symlink.

-nameserver 192.168.0.5

-nameserver 192.168.0.4

-nameserver 8.8.8.8

-```

-

-Let's run a simple Docker app and see if we can resolve it in DNS.

-

-```

-client:~/mesos/jobs$ cat docker.json

-{

-    "id": "docker-hello",

-    "container": {

-        "docker": {

-            "image": "centos"

-        },

-        "type": "DOCKER",

-        "volumes": []

-    },

-    "cmd": "echo hello; sleep 10000",

-    "mem": 16,

-    "cpus": 0.1,

-    "instances": 10,

-    "disk": 0.0,

-    "ports": [0]

-}

-```

-```

-client:~/mesos/jobs$ dcos marathon app add docker.json

-```

-

-Let's try to resolve it.

-

-```

-root@pt-mesos-node2 [ ~/mesos-dns ]# dig _docker-hello._tcp.marathon.mesos SRV

-;; Truncated, retrying in TCP mode.

-; <<>> DiG 9.10.1-P1 <<>> _docker-hello._tcp.marathon.mesos SRV

-;; global options: +cmd

-;; Got answer:

-;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25958

-;; flags: qr aa rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 10

-;; QUESTION SECTION:

-;_docker-hello._tcp.marathon.mesos. IN SRV

-;; ANSWER SECTION:

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31998 docker-hello-4bjcf-s2.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31844 docker-hello-jexm6-s1.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31111 docker-hello-6ms44-s2.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31719 docker-hello-muhui-s2.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31360 docker-hello-jznf4-s1.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31306 docker-hello-t41ti-s1.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31124 docker-hello-mq3oz-s1.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31816 docker-hello-tcep8-s1.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31604 docker-hello-5uu37-s1.marathon.slave.mesos.

-_docker-hello._tcp.marathon.mesos. 60 IN SRV 0 0 31334 docker-hello-jqihw-s1.marathon.slave.mesos.

- 

-;; ADDITIONAL SECTION:

-docker-hello-muhui-s2.marathon.slave.mesos. 60 IN A 192.168.0.5

-docker-hello-4bjcf-s2.marathon.slave.mesos. 60 IN A 192.168.0.5

-docker-hello-jexm6-s1.marathon.slave.mesos. 60 IN A 192.168.0.6

-docker-hello-jqihw-s1.marathon.slave.mesos. 60 IN A 192.168.0.6

-docker-hello-mq3oz-s1.marathon.slave.mesos. 60 IN A 192.168.0.6

-docker-hello-tcep8-s1.marathon.slave.mesos. 60 IN A 192.168.0.6

-docker-hello-6ms44-s2.marathon.slave.mesos. 60 IN A 192.168.0.5

-docker-hello-t41ti-s1.marathon.slave.mesos. 60 IN A 192.168.0.4

-docker-hello-jznf4-s1.marathon.slave.mesos. 60 IN A 192.168.0.4

-docker-hello-5uu37-s1.marathon.slave.mesos. 60 IN A 192.168.0.4

-;; Query time: 0 msec

-;; SERVER: 192.168.0.5#53(192.168.0.5)

-;; WHEN: Sun Dec 27 14:36:32 UTC 2015

-;; MSG SIZE  rcvd: 1066

-```

-

-We can see that we can resolve our app.

\ No newline at end of file

deleted file mode 100644

@@ -1,175 +0,0 @@

-# Install and Configure a Production Ready Mesos Cluster on Photon OS

-

-## Overview

-

-For this setup I will use 3 Mesos masters and 3 slaves. On each Mesos master I will run a Zookeeper, meaning that we will have 3 Zookeepers as well. The Mesos cluster will be configured with a quorum of 2. For networking Mesos use Mesos-DNS. I tried to run Mesos-DNS as container, but got into some resolving issues, so in my next How-To I will explain how to configure Mesos-DNS and run it through Marathon. Photon hosts will be used for masters and slaves.

-

-**Masters:**

-

-| Hostname | IP Address|

-|-

-| pt-mesos-master1.example.com | 192.168.0.1 |

-| pt-mesos-master2.example.com | 192.168.0.2 |

-| pt-mesos-master3.example.com | 192.168.0.3 |

-

-**Agents:**

-

-| Hostname | IP Address|

-|-

-| pt-mesos-node1.example.com | 192.168.0.4 |

-| pt-mesos-node2.example.com | 192.168.0.5 |

-| pt-mesos-node3.example.com | 192.168.0.6

-

-## Masters Installation and Configuration 

-

-First of all we will install Zookeeper. Since currently there is a bug in Photon related to the Zookeeper installation I will use the tarball. Do the following for each master:

-

-```

-root@pt-mesos-master1 [ ~ ]# mkdir -p /opt/mesosphere && cd /opt/mesosphere && wget http://apache.mivzakim.net/zookeeper/stable/zookeeper-3.4.7.tar.gz

-root@pt-mesos-master1 [ /opt/mesosphere ]# tar -xf zookeeper-3.4.7.tar.gz && mv zookeeper-3.4.7 zookeeper

-root@pt-mesos-master1 [ ~ ]# cat /opt/mesosphere/zookeeper/conf/zoo.cfg | grep -v '#'

-tickTime=2000

-initLimit=10

-syncLimit=5

-dataDir=/var/lib/zookeeper

-clientPort=2181

-server.1=192.168.0.1:2888:3888

-server.2=192.168.0.2:2888:3888

-server.3=192.168.0.3:2888:3888

-```

-

-Example of Zookeeper systemd configuration file:

-```

-root@pt-mesos-master1 [ ~ ]# cat /etc/systemd/system/zookeeper.service

-[Unit]

-Description=Apache ZooKeeper

-After=network.target

- 

-[Service]

-Environment="JAVA_HOME=/opt/OpenJDK-1.8.0.51-bin"

-WorkingDirectory=/opt/mesosphere/zookeeper

-ExecStart=/bin/bash -c "/opt/mesosphere/zookeeper/bin/zkServer.sh start-foreground"

-Restart=on-failure

-RestartSec=20

-User=root

-Group=root

- 

-[Install]

-WantedBy=multi-user.target

-```

-

-Add server id to the configuration file, so zookeeper will understand the id of your master server. 

-This should be done for each master with its own id.

-

-```

-root@pt-mesos-master1 [ ~ ]# echo 1 > /var/lib/zookeeper/myid

-root@pt-mesos-master1 [ ~ ]# cat /var/lib/zookeeper/myid

-1

-```

-

-Now lets install the Mesos masters. Do the following for each master:

-```

-root@pt-mesos-master1 [ ~ ]# yum -y install mesos

-Setting up Install Process

-Package mesos-0.23.0-2.ph1tp2.x86_64 already installed and latest version

-Nothing to do

-root@pt-mesos-master1 [ ~ ]# cat /etc/systemd/system/mesos-master.service

-[Unit]

-Description=Mesos Slave

-After=network.target

-Wants=network.target

- 

-[Service]

-ExecStart=/bin/bash -c "/usr/sbin/mesos-master \

-    --ip=192.168.0.1 \

-    --work_dir=/var/lib/mesos \

-    --log_dir=/var/log/mesos \

-    --cluster=EXAMPLE \

-    --zk=zk://192.168.0.1:2181,192.168.0.2:2181,192.168.0.3:2181/mesos \

-    --quorum=2"

-KillMode=process

-Restart=always

-RestartSec=20

-LimitNOFILE=16384

-CPUAccounting=true

-MemoryAccounting=true

- 

-[Install]

-WantedBy=multi-user.target

-```

-

-Make sure you replace *ip* setting on each master. So far we have 3 masters with a Zookeeper and Mesos packages installed. Let's start zookeeper and mesos-master services on each master:

-

-```

-root@pt-mesos-master1 [ ~ ]# systemctl start zookeeper

-root@pt-mesos-master1 [ ~ ]# systemctl start mesos-master

-root@pt-mesos-master1 [ ~ ]# ps -ef | grep mesos

-root     11543     1  7 12:09 ?        00:00:01 /opt/OpenJDK-1.8.0.51-bin/bin/java -Dzookeeper.log.dir=. -Dzookeeper.root.logger=INFO,CONSOLE -cp /opt/mesosphere/zookeeper/bin/../build/classes:/opt/mesosphere/zookeeper/bin/../build/lib/*.jar:/opt/mesosphere/zookeeper/bin/../lib/slf4j-log4j12-1.6.1.jar:/opt/mesosphere/zookeeper/bin/../lib/slf4j-api-1.6.1.jar:/opt/mesosphere/zookeeper/bin/../lib/netty-3.7.0.Final.jar:/opt/mesosphere/zookeeper/bin/../lib/log4j-1.2.16.jar:/opt/mesosphere/zookeeper/bin/../lib/jline-0.9.94.jar:/opt/mesosphere/zookeeper/bin/../zookeeper-3.4.7.jar:/opt/mesosphere/zookeeper/bin/../src/java/lib/*.jar:/opt/mesosphere/zookeeper/bin/../conf: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /opt/mesosphere/zookeeper/bin/../conf/zoo.cfg

-root     11581     1  0 12:09 ?        00:00:00 /usr/sbin/mesos-master --ip=192.168.0.1 --work_dir=/var/lib/mesos --log_dir=/var/lob/mesos --cluster=EXAMPLE --zk=zk://192.168.0.2:2181,192.168.0.1:2181,192.168.0.3:2181/mesos --quorum=2

-root     11601  9117  0 12:09 pts/0    00:00:00 grep --color=auto mesos

-```

-

-## Slaves Installation and Configuration 

-

-The steps for configuring a Mesos slave are very simple and not very different from master installation. The difference is that we won't install zookeeper on each slave. We will also start the Mesos slaves in slave mode and will tell the daemon to join the Mesos masters. Do the following for each slave:

-

-```

-root@pt-mesos-node1 [ ~ ]# cat /etc/systemd/system/mesos-slave.service

-[Unit]

-Description=Photon instance running as a Mesos slave

-After=network-online.target,docker.service

-  

-[Service]

-Restart=on-failure

-RestartSec=10

-TimeoutStartSec=0

-ExecStartPre=/usr/bin/rm -f /tmp/mesos/meta/slaves/latest

-ExecStart=/bin/bash -c "/usr/sbin/mesos-slave \

-    --master=zk://192.168.0.1:2181,192.168.0.2:2181,192.168.0.3:2181/mesos \

-        --hostname=$(/usr/bin/hostname) \

-        --log_dir=/var/log/mesos_slave \

-        --containerizers=docker,mesos \

-        --docker=$(which docker) \

-        --executor_registration_timeout=5mins \

-        --ip=192.168.0.4"

-  

-[Install]

-WantedBy=multi-user.target

-```

-

-Please make sure to replace the NIC name under *ip* setting. Start the mesos-slave service on each node.

-

-Now you should have ready Mesos cluster with 3 masters, 3 Zookeepers and 3 slaves. 

-

-If you want to use private docker registry, you will need to edit docker systemd file. 

-

-In my example I am using cse-artifactory.eng.vmware.com registry:

-

-```

-root@pt-mesos-node1 [ ~ ]# cat /lib/systemd/system/docker.service

-[Unit]

-Description=Docker Daemon

-Wants=network-online.target

-After=network-online.target

-  

-[Service]

-EnvironmentFile=-/etc/sysconfig/docker

-ExecStart=/bin/docker -d $OPTIONS -s overlay

-ExecReload=/bin/kill -HUP $MAINPID

-KillMode=process

-Restart=always

-MountFlags=slave

-LimitNOFILE=1048576

-LimitNPROC=1048576

-LimitCORE=infinity

-  

-[Install]

-WantedBy=multi-user.target

-  

-root@pt-mesos-node1 [ ~ ]# cat /etc/sysconfig/docker

-OPTIONS='--insecure-registry cse-artifactory.eng.vmware.com'

-root@pt-mesos-node1 [ ~ ]# systemctl daemon-reload && systemctl restart docker

-root@pt-mesos-node1 [ ~ ]# ps -ef | grep cse-artifactory

-root      5286     1  0 08:39 ?        00:00:00 /bin/docker -d --insecure-registry <your_privet_registry> -s overlay

-```

-

deleted file mode 100644

@@ -1,287 +0,0 @@

-# Install and Configure a Swarm Cluster with DNS Service on PhotonOS

-

-## Overview

-

-In this How-To, the steps for installing and configuring a Docker Swarm cluster, alongside DNS and Zookeeper, will be presented.

-

-The cluster that will be set up will be on VMware Photon hosts. 

-

-A prerequisite to using this guide is to be familiar with Docker Swarm - information can be found [here](https://docs.docker.com/swarm/).

-

-## Cluster description

-

-The cluster will have 2 Swarm Managers and 3 Swarm Agents:

-

-**Master**

-

-| Hostname | IP Address|

-|-

-| pt-swarm-master1.example.com | 192.168.0.1 |

-| pt-swarm-master2.example.com | 192.168.0.2 |

-

-**Agents**

-

-| Hostname | IP Address|

-|-

-| pt-swarm-agent1.example.com | 192.168.0.3 |

-| pt-swarm-agent2.example.com | 192.168.0.4 |

-| pt-swarm-agent3.example.com | 192.168.0.5 |

-

-## Docker Swarm Installation and Configuration

-

-### Setting Up the Managers

-

-The following steps should be done on both managers.

-

-Docker Swarm supports multiple methods of using service discovery, but in order to use failover, Consul, etcd or Zookeeper must be used. In this guide, Zookeeper will be used.

-

-Download the latest stable version of Zookeeper and create the *zoo.cfg* file under the *conf* directory:

-

-#### Zookeeper installation

-

-```

-root@pt-swarm-master1 [ ~ ]# mkdir -p /opt/swarm && cd /opt/swarm && wget http://apache.mivzakim.net/zookeeper/stable/zookeeper-3.4.6.tar.gz

-root@pt-swarm-master1 [ /opt/swarm ]# tar -xf zookeeper-3.4.6.tar.gz && mv zookeeper-3.4.6 zookeeper

-root@pt-swarm-master1 [ ~ ]# cat /opt/swarm/zookeeper/conf/zoo.cfg | grep -v '#'

-tickTime=2000

-initLimit=10

-syncLimit=5

-dataDir=/var/lib/zookeeper

-clientPort=2181

-server.1=192.168.0.1:2888:3888

-server.2=192.168.0.2:2888:3888

-```

-

-The dataDir should be an empty, existing directory.

-From the Zookeeper documentation: Every machine that is part of the ZooKeeper ensemble should know about every other machine in the ensemble. You accomplish this with the series of lines of the form server.id=host:port:port. You attribute the server id to each machine by creating a file named myid, one for each server, which resides in that server's data directory, as specified by the configuration file parameter dataDir. The myid file consists of a single line containing only the text of that machine's id. So myid of server 1 would contain the text "1" and nothing else. The id must be unique within the ensemble and should have a value between 1 and 255.

-

-Set Zookeeper ID

-```

-root@pt-swarm-master1 [ ~ ]# echo 1 > /var/lib/zookeeper/myid

-</source><br />

-Project Photon uses [https://en.wikipedia.org/wiki/Systemd Systemd] for services, so a zookeeper service should be created using systemd unit file.<br />

-<source lang="bash" enclose="div">

-root@pt-swarm-master1 [ ~ ]# cat /etc/systemd/system/zookeeper.service

-[Unit]

-Description=Apache ZooKeeper

-After=network.target

- 

-[Service]

-Environment="JAVA_HOME=/opt/OpenJDK-1.8.0.51-bin"

-WorkingDirectory=/opt/swarm/zookeeper

-ExecStart=/bin/bash -c "/opt/swarm/zookeeper/bin/zkServer.sh start-foreground"

-Restart=on-failure

-RestartSec=20

-User=root

-Group=root

- 

-[Install]

-WantedBy=multi-user.target

-```

-

-Zookeeper comes with OpenJDK, so having Java on the Photon host is not a prerequisite. Simply direct the Environment variable to the location where the Zookeeper was extracted.

-Now you need to enable and start the service. Enabling the service will make sure that if the host restarts for some reason, the service will automatically start.

-

-```

-root@pt-swarm-master1 [ ~ ]# systemctl enable zookeeper

-root@pt-swarm-master1 [ ~ ]# systemctl start zookeeper

-</source><br />

-Verify that the service was able to start:<br />

-<source lang="bash" enclose="div">

-root@pt-swarm-master1 [ ~ ]# systemctl status zookeeper

-zookeeper.service - Apache ZooKeeper

-   Loaded: loaded (/etc/systemd/system/zookeeper.service; enabled)

-   Active: active (running) since Tue 2016-01-12 00:27:45 UTC; 10s ago

- Main PID: 4310 (java)

-   CGroup: /system.slice/zookeeper.service

-           `-4310 /opt/OpenJDK-1.8.0.51-bin/bin/java -Dzookeeper.log.dir=. -Dzookeeper.root.logger=INFO,CONSOLE -cp /opt/swarm/zookeeper/bin/../build/classes:/opt/swarm/zookeeper/bin/../build/lib/*.jar:/opt/s...

-```

-

-On the Manager you elected to be the Swarm Leader (primary), execute the following (if you do not have a specific leader in mind, choose one of the managers randomly):

-

-```

-root@pt-swarm-master1 [ ~ ]# docker run -d --name=manager1 -p 8888:2375 swarm manage --replication --advertise 192.168.0.1:8888 zk://192.168.0.1,192.168.0.2/swarm

-```

-

-* *docker run -d* - run the container in the background.

-* *--name=manager1* - give the container a name instead of the auto-generated one.

-* *-p 8888:2375* - publish a container's port(s) to the host. In this case, when you connect to the host in port 8888, it connects to the container in port 2375.

-* swarm - the image to use for the container.

-* manage - the command to send to the container once it's up, alongside the rest of the parameters.

-* *--replication* - tells swarm that the manager is part of a a multi-manager configuration and that this primary manager competes with other manager instances for the primary role. The primary manager has the authority to manage the cluster, replicate logs, and replicate events that are happening inside the cluster.

-* *--advertise 192.168.0.1:8888* - specifies the primary manager address. Swarm uses this address to advertise to the cluster when the node is elected as the primary.

-* *zk://192.168.0.1,192.168.0.2/swarm* - specifies the Zookeepers' location to enable service discovery. The /swarm path is arbitrary, just make sure that every node that joins the cluster specifies that same path (it is meant to enable support for multiple clusters with the same Zookeepers).

-

-On the second manager, execute the following:

-

-```

-root@pt-swarm-master2 [ ~ ]# docker run -d --name=manager2 -p 8888:2375 swarm manage --replication --advertise 192.168.0.2:8888 zk://192.168.0.1,192.168.0.2/swarm

-```

-

-Notice that the only difference is the --advertise flag value. The first manager will not lose leadership following this command.

-

-Now 2 managers are alive, one is the primary and another is the replica. When we now look at the docker info on our primary manager, we can see the following information:

-

-```

-docker-client:~$ docker -H tcp://192.168.0.1:8888 info

-Containers: 0

-Images: 0

-Role: primary

-Strategy: spread

-Filters: health, port, dependency, affinity, constraint

-Nodes: 0

-CPUs: 0

-Total Memory: 0 B

-Name: 82b8516efb7c

-```

-

-There are a few things that are worth noticing:

-

-* The info command can be executed from ANY machine that can reach the master. The -H tcp://<ip>:<port> command specifies that the docker command should be executed on a remote host.

-* Containers - this is the result of the docker ps -a command for the cluster we just set up.

-* Images - the result of the docker images command.

-* Role - as expected, this is the primary manager.

-* Strategy - Swarm has a number of strategies it supports for setting up containers in the cluster. spread means that a new container will run on the node with the least amount of containers on it.

-* Filters - Swarm can choose where to run containers based on different filters supplied in the command line. More info can be found [here](https://docs.docker.com/swarm/scheduler/filter/).

-

-

-When we now look at the docker info on our replicated manager, we can see the following information:

-

-```

-docker-client:~$ docker -H tcp://192.168.0.2:8888 info

-Containers: 0

-Images: 0

-Role: replica

-Primary: 192.168.0.1:8888

-Strategy: spread

-Filters: health, port, dependency, affinity, constraint

-Nodes: 0

-CPUs: 0

-Total Memory: 0 B

-Name: ac06f826e507

-```

-

-Notice that the only differences between both managers are:

-Role: as expected, this is the replicated manager.

-Primary: contains the primary manager.

-

-#### Setting Up the Agents

-

-In Swarm, in order for a node to become a part of the cluster, it should "join" that said cluster - do the following for each of the agents.

-Edit the */usr/lib/systemd/system/docker.service* file so that each agent will be able to join the cluster:

-

-```

-root@pt-swarm-agent1 [ ~ ]# cat /usr/lib/systemd/system/docker.service

-[Unit]

-Description=Docker Daemon

-Wants=network-online.target

-After=network-online.target

- 

-[Service]

-ExecStart=/bin/docker daemon -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --cluster-advertise eno16777984:2375 --cluster-store zk://192.168.0.1,192.168.0.2/swarm

-ExecReload=/bin/kill -HUP $MAINPID

-KillMode=process

-Restart=always

-MountFlags=slave

-LimitNOFILE=1048576

-LimitNPROC=1048576

-LimitCORE=infinity

- 

-[Install]

-WantedBy=multi-user.target

-```

-

-* -H tcp://0.0.0.0:2375 - This ensures that the Docker remote API on Swarm Agents is available over TCP for the Swarm Manager.

-* -H unix:///var/run/docker.sock - The Docker daemon can listen for Docker Remote API requests via three different types of Socket: unix, tcp, and fd. 

-    * tcp - If you need to access the Docker daemon remotely, you need to enable the tcp Socket.

-    * fd - On Systemd based systems, you can communicate with the daemon via Systemd socket activation.

-* *--cluster-advertise <NIC>:2375* - advertises the machine on the network by stating the ethernet card and the port used by the Swarm Managers.

-* --cluster-store zk://192.168.0.1,192.168.0.2/swarm - as we defined before, the service discovery being used here is Zookeeper.

-

-Enable and start the docker service:

-

-```

-root@pt-swarm-agent1 [ ~ ]# systemctl enable docker

-root@pt-swarm-agent1 [ ~ ]# systemctl daemon-reload && systemctl restart docker

-root@pt-swarm-agent1 [ ~ ]# systemctl status docker

-docker.service - Docker Daemon

-   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)

-   Active: active (running) since Tue 2016-01-12 00:46:18 UTC; 4s ago

- Main PID: 11979 (docker)

-   CGroup: /system.slice/docker.service

-           `-11979 /bin/docker daemon -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --cluster-advertise eno16777984:2375 --cluster-store zk://192.168.0.1,192.168.0.2/swarm

-```

-

-All that remains is to have the agents join the cluster:

-```

-root@pt-swarm-agent1 [ ~ ]# docker run -d swarm join --advertise=192.168.0.3:2375 zk://192.168.0.1,192.168.0.2/swarm

-```

-

-A look at the output of the docker info command will now show:

-```

-docker-client:~$ docker -H tcp://192.168.0.1:8888 info

-Containers: 3

-Images: 9

-Role: primary

-Strategy: spread

-Filters: health, port, dependency, affinity, constraint

-Nodes: 3

- pt-swarm-agent1.example.com: 192.168.0.3:2375

-  └ Status: Healthy

-  └ Containers: 1

-  └ Reserved CPUs: 0 / 1

-  └ Reserved Memory: 0 B / 2.055 GiB

-  └ Labels: executiondriver=native-0.2, kernelversion=4.1.3-esx, operatingsystem=VMware Photon/Linux, storagedriver=overlay

- pt-swarm-agent2.example.com: 192.168.0.4:2375

-  └ Status: Healthy

-  └ Containers: 1

-  └ Reserved CPUs: 0 / 1

-  └ Reserved Memory: 0 B / 2.055 GiB

-  └ Labels: executiondriver=native-0.2, kernelversion=4.1.3-esx, operatingsystem=VMware Photon/Linux, storagedriver=overlay

- pt-swarm-agent3.example.com: 192.168.0.5:2375

-  └ Status: Healthy

-  └ Containers: 1

-  └ Reserved CPUs: 0 / 1

-  └ Reserved Memory: 0 B / 2.055 GiB

-  └ Labels: executiondriver=native-0.2, kernelversion=4.1.3-esx, operatingsystem=VMware Photon/Linux, storagedriver=overlay

-CPUs: 3

-Total Memory: 6.166 GiB

-Name: 82b8516efb7c

-```

-

-#### Setting Up DNS

-

-Docker does not have its own self-provided DNS so we use a [https://github.com/ahmetalpbalkan/wagl wagl] DNS.

-Setting it up is very simple. In this case, one of the masters will also be the DNS. Simply execute:

-

-```

-docker-client:~$ docker run -d --restart=always --name=dns -p 53:53/udp --link manager1:swarm ahmet/wagl wagl --swarm tcp://swarm:2375

-```

-

-* *--restart=always* - Always restart the container regardless of the exit status. When you specify always, the Docker daemon will try to restart the container continuously. The container will also always start on daemon startup, regardless of the current state of the container.

-* *--link manager1:swarm* - link the manager1 container (by name) and give it the alias swarm.

-That's it, DNS is up and running.

-

-### Test Your Cluster 

-

-#### Running Nginx

-

-Execute the following commands from any docker client:

-

-```

-docker-client:~$ docker -H tcp://192.168.0.1:8888 run -d -l dns.service=api -l dns.domain=example -p 80:80 vmwarecna/nginx

-docker-client:~$ docker -H tcp://192.168.0.1:8888 run -d -l dns.service=api -l dns.domain=example -p 80:80 vmwarecna/nginx

-```

-

-Note that this is the same command, executed twice. It tells the master to run 2 of the similar containers, each of which has 2 dns labels.

-

-Now, from any container in the cluster that has dnsutils, you can execute the following (for example):

-

-```

-root@13271a2d0fcb:/# dig +short A api.example.swarm

-192.168.0.3

-192.168.0.4

-root@13271a2d0fcb:/# dig +short SRV _api._tcp.example.swarm

-1 1 80 192.168.0.3.

-1 1 80 192.168.0.4.

-```

new file mode 100644

@@ -0,0 +1,22 @@

+# Overview of Photon OS

+

+*Overview of Photon OS* provides an introduction to Photon OS, it versions, and distinguishing features.

+

+**Product version: 3.0**

+

+This documentation applies to all 3.0.x releases.

+

+## Intended Audiences

+

+This information is intended for Photon OS administrators who install and set up Photon OS.

+

+----------

+

+Copyright © 2016-2018 VMware, Inc. All rights reserved. [Copyright and trademark information](http://pubs.vmware.com/copyright-trademark.html). Any feedback you provide to VMware is subject to the terms at [www.vmware.com/community_terms.html](http://www.vmware.com/community_terms.html).

+

+**VMware, Inc.**<br>

+3401 Hillview Ave.<br>

+Palo Alto, CA 94304

+

+[www.vmware.com](http://www.vmware.com)

+

deleted file mode 100644

@@ -1,52 +0,0 @@

-# Introduction

-

-## 1.1 What is OSTree? How about RPM-OSTree?

-

-OSTree is a tool to manage bootable, immutable, versioned filesystem trees. Unlike traditional package managers like rpm or dpkg that know how to install, uninstall, configure packages, OSTree has no knowledge of the relationship between files. But when you add rpm capabilities on top of OSTree, it becomes RPM-OSTree, meaning a filetree replication system that is also package-aware.   

-The idea behind it is to use a client / server architecture to keep your Linux installed machines (physical or VM) in sync with the latest bits, in a predictable and reliable manner. To achieve that, OSTree uses a git-like repository that records the changes to any file and replicate them to any subscriber.  

-A system administrator or an image builder developer takes a base Linux image, prepares the packages and other configuration on a server box, executes a command to compose a filetree that the host machines will download and then incrementally upgrade whenever a new change has been committed.

-You may read more about OSTree [here](https://wiki.gnome.org/Projects/OSTree).

-

-## 1.2 Why use RPM-OSTree in Photon?

-There are several important benefits:

-* Reliable, efficient: The filetree replication is simple, reliable and efficient. It will only transfer deltas over the network. If you have deployed two almost identical bootable images on same box (differing just by several files), it will not take twice the space. The new tree will have a set of hardlinks to the old tree and only the different files will have a separate copy stored to disk.

-* Atomic: the filetree replication is atomic. At the end of a deployment, you are either booting from one deployment, or the other. There is no "partial deployed bootable image". If anything bad happens during replication or deployment- power loss, network failure, your machine boots from the old image. There is even a tool option to cleanup old deployed (successfully or not) image.

-* Manageable: You are provided simple tools to figure out exactly what packages have been installed, to compare files, configuration and package changes between versions.

-* Predictable, repeatable: A big headache for a system administrator is to maintain a farm of computers with different packages, files and configuration installed in different order, that will result in exponential set of test cases. With RPM-OStree, you get identical, predictable installed systems. 

-

-As drawbacks, I would mention:

-* Some applications configured by user on host may have compatibility issues if they save configuration or download into read only directories like /usr.

-* People not used with "read only" file systems will be disappointed that they could no longer use RPM, yum, tdnf to install whatever they want. Think of this as an "enterprise policy". They may circumvent this by customizing the target directory to a writable directory like /var or using rpm to install packages and record them using a new RPM repository in a writable place.

-* Administrators need to be aware about the directories re-mapping specific to OSTree and plan accordingly.

-

-## 1.3 Photon with RPM-OSTree installation profiles

-Photon takes advantage of RPM-OSTree and offers several installation choices:

-* Photon RPM-OSTree server - used to compose customized Photon OS installations and to prepare updates. I will call it for short 'server'.

-* Photon RPM-OSTree host connected to a default online server repository via http or https, maintained by VMware Photon OS team, where future updates will be published. This will create a minimal installation profile, but with the option to self-upgrade. I will call it for short 'default host'.

-* Photon RPM-OSTree host connected to a custom server repository. It requires a Photon RPM-OSTree Server installed in advance. I will call it for short 'custom host'.

-

-## 1.4 Terminology

-I use the term "OSTree" (starting with capitals) throughout this document, when I refer to the general use of this technology, the format of the repository or replication protocol. I use "RPM-OSTree" to emphasize the layer that adds RedHat Package Manager compatibility on both ends - at server and at host. However, since Photon OS is an RPM-based Linux, there are places in the documentation and even in the installer menus where "OSTree" may be used instead of "RPM-OSTree" when the distinction is not obvious or doesn't matter in that context.

-When "ostree" and "rpm-ostree" (in small letters) are encountered, they refer to the usage of the specific Unix commands.   

-

-Finally, "Photon RPM-OSTree" is the application or implementation of RPM-OStree system into Photon OS, materialized into two options: Photon Server and Photon Host (or client). "Server" or "Host" may be used with or without the "Photon" and/or "RPM-OStree" qualifier, but it means the same thing. 

-

-## 1.5 Sample code

-Codes samples used throughout the book are small commands that can be typed at shell command prompt and do not require downloading additional files. As an alternative, one can remote via ssh, so cut & paste sample code from outside sources or copy files via scp will work. See the Photon Administration guide to learn [how to enable ssh](photon-admin-guide.md#permitting-root-login-with-ssh). 

-The samples assume that the following VMs have been installed - see the steps in the next chapters:

-* A default host VM named **photon-host-def**.

-* Two server VMs named **photon-srv1** and **photon-srv2**.

-* Two custom host VMs named **photon-host-cus1** and **photon-host-cus2**, connected each to the corresponding server during install.

-

-## 1.6 How to read this book

-I've tried to structure this book to be used both as a sequential read and as a reference documentation.   

-If you are just interested in deploying a host system and keeping it up to date, then read chapters 2 and 5.   

-If you want to install your own server and experiment with customizing packages for your Photon hosts, then read chapters 6 to 9. There are references to the concepts discussed throughout the book, if you need to understand them better.  

-However, if you want to read page by page, information is presented from simple to complex, although as with any technical book, we occasionally run into the chicken and egg problem - forward references to concepts that have yet to be explained later. In other cases, concepts are introduced and presented in great detail that may be seem hard to follow at first, but I promise they will make sense in the later pages when you get to use them.

-

-## 1.7 Difference between versions

-This book has been written when Photon 1.0 was released, so all the information presented apply directly to Photon 1.0 and also to Photon 1.0 Revision 2 (in short Photon 1.0 Rev2 or Photon 1.0r, as some people refer to it as Photon 1.0 Refresh). This release is relevant to OSTree, because of ISO including an updated RPM-OSTree repository containing upgraded packages, as well as matching updated online repo that plays well into the upgrade story. Other than that, differences are minimal.  

-

-The guide has been updated significantly for Photon OS 2.0. Information of what's different is scattered through chapters 2, 6, 7, 8. [Install or rebase to Photon OS 2.0](Photon-RPM-OSTree-Install-or-rebase-to-Photon-OS-2.0.md) is dedicated to the topic.    

-

-OSTree technology is evolving too and rather than pointing out at what package version some feature has been introduced or changed, the focus is on the ostree and rpm-ostree package versions included with the Photon OS major releases.

deleted file mode 100644

@@ -1,89 +0,0 @@

-# Remotes

-

-In Chapter 3 we talked about the Refspec that contains a **photon:** prefix, that is the name of a remote. When a Photon host is installed, a remote is added - which contains the URL for an OSTree repository that is the origin of the commits we are going to pull from and deploy filetrees, in our case the Photon RPM-OSTree server we installed the host from. This remote is named **photon**, which may be confusing, because it's also the OS name and part of the Refspec (branch) path.

-

-## 10.1 Listing remotes

-A host repo can be configured to switch between multiple remotes to pull from, however only one remote is the "active" one at a time. We can list the remotes created so far, which brings back the expected result.

-```

-root@photon-host-def [ ~ ]# ostree remote list

-photon

-```

-We can inquiry about the URL for that remote name, which for the default host is the expected Photon OS online OSTree repo.

-```

-root@photon-host-def [ ~ ]# ostree remote show-url photon

-https://dl.bintray.com/vmware/photon/rpm-ostree/1.0

-```

-But where is this information stored? The repo's config file has it.

-```

-root@photon-host-def [ ~ ]# cat /ostree/repo/config 

-[core]

-repo_version=1

-mode=bare

-

-[remote "photon"]

-url=https://dl.bintray.com/vmware/photon/rpm-ostree/1.0