#aptible

fancyremarker: is it currently possible/easy to link two application containers? /cc wayne

ie, native docker --link

not currently — we chose not to use Docker linking in favor of ordinary TCP linking on explicit hosts/ports to start — what's the use case? i can think through how we might supportit (feel free to PM)

fancyremarker: so, wayne and I were thinking of how to allow full text-search for our application even without database support for elasticsearch (yet)

and it turns out that since the data size is still relatively small and we don't really need the persistence for that we could just create a new application that runs elasticsearch using the temporary filesystem

but we would have no way of communicating between that and our web application instance

ah! got it.

so, a few answers

the easiest answer is that Elasticsearch is actually supported at the moment, just only through `aptible db:create` and not on Dashboard

we don't have the full container output—Elasticsearch log routing deployed yet, but aaw has made a ton of progress on that

aha!

ahhhh

got it

I didn't realize the bottleneck now was the routing portion

okay, so that's much easier

wayne: ^

but if you only need Elasticsearch for a database that you interact with directly from your app, you're okay

sorry about that miscommunication — my fault

nah np

I think you mentioned it before but I forgot

the other piece is that you can get IP addresses for app containers

just not through the UI currenlty

but in general our api routes map isomorphically to our dashboard routes

ah

so, if for example, you have an app with id: 123

it just so happens that we do have an app with id 123

ah got it

:)

so sounds like it would work

hahahahahaa

wayne: we are the chosen ones

yeah that's why i picked it

haha

this isn't the most straightforward way, but if you have a JSON viewer extension like "JSON Formatter" [0], you can browse that API: services —> (pick the service, e.g. "web") —> current_release —> containers

that will show the host/port

can https://api.aptible.com/apps/123 be accessed with the container without auth?

i.e. the fact that it has the right interface serves as auth

alternatively, with the aptible-api gem [1]: `App.find(123, token: token).services[i].current_release.containers`

[0] https://github.com/callumlocke/json-formatter

[1] https://github.com/aptible/aptible-api-ruby

wayne: no, not currently — but that's a good idea. that would be roughly akin to AWS' instance roles

i.e., an account's containers would be authorized to Aptible API resources sans authentication

anyway, that was more just to illustrate how to access the host/port for an app — in this case, i'd probably recommend an elasticsearch db

alright i'll fire one up and give it a shot

thanks

np

nice that Procfiles let us run multiple processes at once

fancyremarker: thank you telling me the steps in the git receive hook

++

thank aaw

but thanks for the feedback! we thought that would be helpful

is the new nginx config loaded?

Oh, wayne, great to meet you last night, btw

likewise

sorry i missed you, fancyremarker

yeah, me too — soon!

just one min wayne, i will merge after running a few tests locally

i haven't tested on SSE yet, so you'll have to let me know if it works there (it may not, and we may need to add the modifications you mentioned)

the http_header 1.1 line should do the trick

ok, it's merged on GitHub [0], this triggers an auto-build on Quay [1]. once that build is ready, any new deploy/restart will use the new NGiNX

[0] https://github.com/aptible/docker-nginx/pull/23

[1] https://quay.io/repository/aptible/nginx

make sense? there's a little "building" badge on Quay that will turn to "ready", should be not too many minutes

nice, thanks

i've been checking out CoreOS for some deployment stuff

i think they're trying to be the kind of platform that aptible itself should live on, but i feel that the tooling is still lacking :/

yeah, CoreOS is very interesting, and we're keeping an eye on it. also: kubernetes

service discovery still hasn't been solved very well, imo

because a lot of these things didn't exist or were very lacking when we started, we rolled our own for a lot of it but ultimately we'd like to be flexible on how we provision our backend, keeping only our own API (where we record ops and compliance states) stable

that's the scary part about the health space imo

a lot of stuff is home-grown because data can't be freely slung around like in a photo-sharing app

(for personal, non-medical photos :P)

i was joking with aditya that i was gonna take that websocket chat example and make it hipaa-compliant, then raise a seed round for it

firebase didn't want to

you definitely could

the funny thing is that it wouldn't be an awful idea

fancyremarker: websockets work just fine. SSEs don't appear to work.

curl -k https://misc-devel-web-foagph-1377577538.us-eas... just times out

for reference, here's what i'm deploying: https://github.com/wyc/go-server-sent-events-ex...

is this the same behavior you saw before?

yeah

k

works on localhost, and a remote digital ocean server

hitting the app directly you mean?

yep

i.e., not through a reverse proxy like NGiNX

k

so, i'll get a chance to look at this this weekend, but probably not this afternoon. if you feel ambitious, you can actually run NGiNX exactly as it's run on Aptible as follows

(it requires Docker)

cool

reverse nginx hot-config is annoying

not that i'll need it

but nginx-proxy is solution, but it's hacky

i build one with etcd and haproxy, but it's still a hack

this goes back to service discovery not being solved well :(

docker run -i -t -p 80:80 -p 443:443 -e UPSTREAM_SERVERS=<app-ip>:<app-port> quay.io/aptible/nginx:experimental

the app IP can't be the loopback address, since that won't make sense to the Docker containers. it needs to be an actual address (can be private)

then you just hit http://<docker-host-ip>

thanks

oh sorry, and the code for that Docker repo is here: https://github.com/aptible/docker-nginx/tree/ex...

and by hot-config i meant docker containers using -P for dynamic port allocation

the problem of getting these containers proper virtual hosts

but again, i won't be needing that to test this haha