Mup Next

[arunoda]

The next version of mup with running docker as the runtime. So, mup will work with any server which supports docker.

Here are files we've

servers.json

{
  "server1": {
    "host": "aa.com",
    "username": "root",
    "pem": "~/ddssds",
    "tags": ["abc", "cc"],
    "env": {

    },
    "sshPort": 23
  },

  "server2": {}
}

config.json

{
  "env": {
    "CLUSTER_DISCOVERY_URL": "kadira://id:secret@kd6.co,kd7.co,kd8.co"
  },

  "settings": {

  }
}

app1.json

{
  "service": "web",
  "type": "meteor",
  // if needed, we can give instructions to use a custom docker image instead of our base docker meteor image
  "docker": {
    "repo": "dd",
    "auth": "dd",
    "password": "sss"
  },
  "nodeVersion": "0.10.33",
  "mongo": true,
  "appPath": "../",
  "sslPem": "~/aa.pem",
  "env": {

  },

  "settings": {

  },

  "deployTo": {
    // deploy to these IPs
    "server1": [80]
  },

  // deploy one after one
  "rollingDeployments": true
}

dockerapp.json

{
  "service": "web",
  "type": "docker",
  "docker": {
    "repo": "dd",
    "auth": "dd",
    "password": "sss"
  },
  "env": {

  },
  "deployTo": {
    // deploy to these IPs
    "server1": [80, 1000],
    // deploy 4 instances with random ports
    "server2": 4
  }
}

These are the commands we can invoke

#!/bin/bash

# install all the docker related tools
mup setup

# limit it to few servers
mup setup server1 server2

# deploy given set of apps
mup deploy app1 goapp

# deploy given app to server 2 only
mup deploy app1:server2

# show logs of app1
mup logs app1 -t -n 300

# get logs of app1 in the server1
mup logs app1:server1s

# get logs of app1 in the server1 and port 80
mup logs app1:server1s:80

mup reconfig

mup start

mup stop

mup undeploy

mup ssh server1

[smeijer]

Will the CLUSTER_DISCOVERY_URL be used in a way that meteor-up will deploy the app to all nodes available in the cluster?

Would be great if we could just use mup deploy {env} and be sure that the entire cluster is updated. The new app-version should spread trough the cluster like a controlled virus.

[arunoda]

Didn't get your comment exactly. But cluster discovery url will be used to load balancing and service discovery.

It's not a mandatory part of mup. Mup doesn't know about it. For mup it just an env variable. On 2015 පෙබ 7, සෙන at ප.ව. 6.04 smeijer notifications@github.com wrote:

Will the CLUSTER_DISCOVERY_URL be used in a way that meteor-up will deploy the app to all nodes available in the cluster https://github.com/meteorhacks/cluster?

Would be great if we could just use mup deploy {env} and be sure that the entire cluster is updated. The new app-version should spread trough the cluster like a controlled virus.

— Reply to this email directly or view it on GitHub https://github.com/arunoda/meteor-up/issues/243#issuecomment-73362556.

[smeijer]

Thanks, I now understand it's purpose.

I was hoping that meteor-up would somehow become aware of the cluster, or that the 'cluster' would be somehow aware of a deployed update.

Let my explain my thoughts a bit, (risking that this should be in a separate issue).

In a perfect world; mup deploy production would deploy the meteor-app myApp to the cluster I tagged as 'production'. Perhaps mup should deploy it to a single node, while that single node informs the other nodes that it is being updated. After update completed, other nodes can pull the new app-version from the already updated node, and should update themselfs.

mup deploy app1:server1 # update an in servers.json registered server
#1. server1 is part of 'cluster1'
#2. cluster1 consists of three servers, server1, server2, and server3
#3. server1 notifies cluster1 that it's being updated, and should be taken out of the pool
#4. server1 updates itself
#5. server1 lets cluster know its back online, and should be taken back into the pool
#6. cluster1 detects server1's more recent app-version, and tells nodes running a older version that they should update
#7. server2 lets cluster know its ready to update, fetches update from cluster1, and goes trough step #3 to #6

meteorhacks:cluster has autodiscovery so servers won't have to be registered in a config file. Which makes auto-scaling very easy, as the new node registers itself to the cluster. I'm afraid that if meteor-up isn't aware of the cluster, or doesn't have the same autodisovery, somehow some servers/nodes are going to run different versions of myApp.

The way I see it, is that currently each automatically created server, has to be registered in 'servers.json' to make sure that mup deploy is deploying the update to every node. And even when I succeed in keeping servers.json in sync with the actually running servers. A server isn't updated if it was hibernating at the moment the update was deployed trough mup.

In a perfect world, that 'hibernating server' will update as soon as it comes up, because the cluster tells him it is running a older version of the app / micro-service.