Starting at boot about dokku-postgres HOT 27 CLOSED

How about we just have a dokku server-restart command? It can be used instead of our current ps:rebuildall called in the dokku init script, and can have it's own pluginhook. That way any developer can go in and decide "oh this needs to happen when the server reboots" for their plugins. It would require a new pluginhook I think.

/cc @michaelshobbs

from dokku-postgres.

👍 I think it’s a far better solution (I was just trying with the current state of dokku)

from dokku-postgres.

ps:rebuildall literally rebuilds all app and subsequently calls all the normal pluginhooks that would have originally started up a datastore plugin's container. why would we need another method of doing the same thing? (or do I not understand what we're talking about here?)

from dokku-postgres.

These plugins aren't applications. Atm when the server restarts, the service containers aren't running because there isn't anything to start them - they don't have --restart=always flag.

from dokku-postgres.

Ah ok. I hadn't read through the code in the plugin. I see that the starting of the container is manual it seems. I handled this via an existing pluginhook when I did dokku-logspout.

https://github.com/michaelshobbs/dokku-logspout/blob/master/pre-build

I'm kinda partial to something like this in order to make sure your service container is definitely up on deploy.

from dokku-postgres.

Oh that's pretty smart. I like that a lot. @Flink Maybe we could do something similar by checking available service->app links and starting those service containers?

from dokku-postgres.

@josegonzalez yeah that’s what I did in psql-sc too (see my opening comment 😜). But what bothers me is that data stores as defined here aren’t necesseraly linked to an app. When you do a postgres:create, you don’t provide an app name as the argument but just the name of your data store. Then it is started. And if you use the expose command on it, another (external) application could use it without using docker links. So then we have a use case where a data store could never be started if no local app use it but where it could be used by something else. (Don’t know if I’m very clear 😁)

from dokku-postgres.

We should definitely add a service:start command that ensures a service is started (maybe even a stop).

What you mentioned just now is what I want to avoid. Perhaps just start all containers for a particular service if they are stopped in that pluginhook? That also seems wrong. What if I stop one service manually and then deploy an app?

from dokku-postgres.

👍 for a start and stop, it’ll simplify some logic (and restart will be easy 😄).

Then we could be a little bit opinionated about what we do. What you mentioned (and what we’re doing with @michaelshobbs in our respective plugins) is certainly the way to go for data stores linked to applications. We could see this as automatically managed containers when there is a link to an app. For the others, we consider them to be manually managed and to be the responsibility of the dokku user(s).

from dokku-postgres.

Fine by me. Want to come up with a pr for that? We can then transpose that to every plugin pretty easily :)

from dokku-postgres.

Yes no problem, so a start, stop and an autostart for containers linked to apps, alright?

from dokku-postgres.

Yep on both

Both commands should optionally take an service name. If no service is specified, all services are affected, otherwise just the single service will be manipulated.

from dokku-postgres.

Ok then, I’ll do that 😉

from dokku-postgres.

@Flink bumpers :)

from dokku-postgres.

@josegonzalez yep sorry, started to work on it but I’ve some weird bugs. So debugging before continuing :)

from dokku-postgres.

Heh the iptables thing doesn't appear to work. I found an alternative golang project that should do the trick, so I'm taking a look at the pr :)

from dokku-postgres.

It doesn’t work because it needs sudo or is it another problem?

from dokku-postgres.

Sudo, but also the rule I added doesn't work.

I was thinking of using something like this: https://github.com/Memset/tcp_fallback

Thoughts?

from dokku-postgres.

Also, we should rip out all the code relating to port exposing now from all plugins or people will assume it works.

from dokku-postgres.

as for dokku/dokku-redis#1, we should certainly use an ambassador to expose service.
So for now, do I rip the exposing code?

from dokku-postgres.

Should be something like this. We should follow a naming convention for the containers, ensure we write the ambassador's container id somewhere, and handle cleanup when unexposing/reloading. Can you test that out in the dokku-redis pr's branch?

from dokku-postgres.

yes I can test that. I still need to make the autostart feature :)

from dokku-postgres.

If you do the ambassador stuff, I can take care of autostart :)

from dokku-postgres.

As you wish 😁 I’ll take a look!

from dokku-postgres.

:)

from dokku-postgres.

I was thinking, one way to autostart service containers is to just use the --restart always option of docker when creating the container. It will only start automatically the container when this one won’t exit properly or when docker starts. Documentation says “Restart policies will ensure that linked containers are started in the correct order” so it seems great for our case.

The only “drawback” is that it’ll start at boot a previously stopped service but does it really matter?

from dokku-postgres.

This is done in all services with the merge of #1.

from dokku-postgres.