google-fabric / galley Goto Github PK

I'm seeing a behavior that doesn't seem to line up with how I expect galley to behave.

Expectation

Setting a service to be stateful should mean that the only time it gets nuked is when I explicitly tell galley to do so (with unprotectStateful and the like)

Observation

database is a stateful service that is a dependency of app:

$ galley run app.dev
database: Checking… not found. Creating… done! Starting… done!
app: Checking… not found. Creating… done! Starting… done!

Make some changes so database's state has changed

$ galley run database.dev
database: Checking… needs recreate Removing… done! Creating… done! Starting… done!

Now, database's state has been lost, when I was just expecting it to relaunch in the foreground.

PR is en route

Current example is based on some fake registry, which does not make sence when users are trying to run and see how it works. It would be much better to demo against docker hub (the default registry) and provide hands-on examples that users can learn from easily by doing.

on OS X:

➜  galley-template git:(master) nvm use 4.2
Now using node v4.2.1 (npm v2.14.7)
➜  galley-template git:(master) galley run demo.dev
demo-mysql:
Error: connect ENOENT /var/run/docker.sock
    at Object.exports._errnoException (util.js:874:11)
    at exports._exceptionWithHostPort (util.js:897:20)
    at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1063:14)%    

Looks like there a few more steps that need to be included in the quick start guide, I assume my docker vm is not running.

$ npm install -g galley-cli
$ git clone https://github.com/twitter-fabric/galley-template.git
$ cd galley-template
$ galley run demo.dev

...npm i...

demo-mysql: Downloading… ⠇ Pulling from library/mysql                                                     
undefined:2
{"status":"Pulling fs layer","progressDetail":{},"id":"9374bfd4d273"}
^
SyntaxError: Unexpected token {
    at Object.parse (native)
    at IncomingMessage.<anonymous> (/private/tmp/galley-demo/galley-template/node_modules/galley/build/lib/lib/docker_utils.js:239:21)
    at IncomingMessage.emit (events.js:95:17)
    at IncomingMessage.<anonymous> (_stream_readable.js:765:14)
    at IncomingMessage.emit (events.js:92:17)
    at emitReadable_ (_stream_readable.js:427:10)
    at emitReadable (_stream_readable.js:423:5)
    at readableAddChunk (_stream_readable.js:166:9)
    at IncomingMessage.Readable.push (_stream_readable.js:128:10)
    at HTTPParser.parserOnBody [as onBody] (http.js:143:22)
    at Socket.socketOnData [as ondata] (http.js:1588:20)
    at Pipe.onread (net.js:528:27)

Versions:
OS X Yosemite 10.10.5

$ node -v && npm -v && galley version
v0.10.36
1.4.2
galley version 1.0.0

Not sure why it keeps barfing while trying to download the mysql docker image.

I have a docker config that looks like this:

{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "SECRET",
            "email": "[email protected]"
        }

    }
}

For some reason, I can pull images with docker pull but if I try to do the same with galley pull, I get errors. I think that https://github.com/twitter-fabric/galley/blob/7cd05cff6f654ca3070fc6982ef84ba1942bd4ad/lib/lib/docker_utils.coffee#L96-L99 is not properly setting the authConfig value, because if I insert these lines below 99:

      else
        opts.authconfig = authConfigFn('https://index.docker.io/v1/')

everything seems to work.

I suspect that the registry value from the Galleyfile CONFIG is not being picked up and that may be related, but I'm not sure.

Any ideas?

A change to how Docker reports links to containers that are no longer present (it now reports them anyway) has broken Galley's logic for some recreates. See: moby/moby#21049

You can currently see this behavior in Galley's failed integration tests on Docker 1.10 and higher.

Unfortunately, the Docker team is not interested in fixing this.

Until we make a workaround, either stay on Docker 1.9 or manually remove containers that Galley tries to start up but fail with "cannot link to non-running container".

I'm puzzling through this right now and I'm not sure if this is a bug or a feature.

I feel like these should be equivalent:

module.exports = {
  'alpha':{
    image: 'alpine',
    ports: ['9001:9001'],
    entrypoint: ['/bin/sleep'],
    command: ['100']
  }
}

docker run -it -p 9000:9000 alpine /bin/sleep 10

But, the one that I run through galley doesn't have the port published:

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                         NAMES
c6c4204c2b46        alpine              "/bin/sleep 10"          4 seconds ago       Up 2 seconds        0.0.0.0:9000->9000/tcp                        amazing_fermat
2cb340eb6140        d6ead20d5571        "/bin/sleep 10"          5 seconds ago       Up 4 seconds                                                      alpha.dev

Am I missing something here?

If I build a container from the following Dockerfile, I can get galley to publish ports, whether or not they're the port exposed in the Dockerfile.

FROM alpine
EXPOSE 9001

I don't know node very well, but if I were to guess, it has something to do with this line:

https://github.com/twitter-fabric/galley/blob/master/lib/commands/run.coffee#L53

Any light you can shed would be great, thanks so much

I'm a big fan of #53 (nice work @samedson!), but I started to experience some issues after upgrading. First, I'm seeing a lot of rsync thrashing (made a gif to illustrate it constantly rsyncing):

Second, I experience a new crash that I've never seen before pre-1.2.0 (which may or may not be related to this PR):

Anyone experiencing similar behavior?