Remove Docker provisioning logic? #389

Closed
opened 2023-01-24 10:58:00 +00:00 by decentral1se · 3 comments
Owner

I'm trying to work through #380 and one part of it is that abra tries to handle provisioning Docker on remote servers.

This complicates the SSH handling because we try to suport both ssh key authentication, ssh password authentication and also, support input of sudo password if not running commands as root on the server 🤯

This is where abra starts to drift into pretending to be a configuration management tool like Ansible or Terraform? But I'm not sure it should.

It would significantly reduce the complexity of managing SSH inside abra if we could remove this functionality. This would help to make SSH handling simpler and more predictable in abra. See tickets referenced from #380 for how many issues we've had with this...

Thoughts? Do people use this feature?

At Autonomic, we're using other tools to provision our servers.

I am a big fan of deleting code.

I'm trying to work through https://git.coopcloud.tech/coop-cloud/organising/issues/380 and one part of it is that `abra` tries to handle provisioning Docker on remote servers. This complicates the SSH handling because we try to suport both ssh key authentication, ssh password authentication and also, support input of sudo password if not running commands as root on the server 🤯 This is where `abra` starts to drift into pretending to be a configuration management tool like Ansible or Terraform? But I'm not sure it should. It would significantly reduce the complexity of managing SSH inside `abra` if we could remove this functionality. This would help to make SSH handling simpler and more predictable in `abra`. See tickets referenced from https://git.coopcloud.tech/coop-cloud/organising/issues/380 for how many issues we've had with this... Thoughts? Do people use this feature? At Autonomic, we're using other tools to provision our servers. I am a big fan of deleting code.
decentral1se added the
question
label 2023-01-24 10:58:00 +00:00
Owner

We also use other tools to provision vms at local-it. Also in terms of seperation of concerns deleting this bit seems to be the right choice to me.

But I still fancy the idea to just type abra server new and get a vm (with best-practice setup) ready to deploy apps.
Maybe interacting with other tools could be a way. For instance we could use Terraform to provision vms and use smth like terranova to interact? Same for -p with ansible ... But not sure it that would mean just a mess of dependencies...

We also use other tools to provision vms at local-it. Also in terms of *seperation of concerns* deleting this bit seems to be the right choice to me. But I still fancy the idea to just type `abra server new` and get a vm (with best-practice setup) ready to deploy apps. Maybe interacting with other tools could be a way. For instance we could use Terraform to provision vms and use smth like [terranova](https://github.com/johandry/terranova) to interact? Same for `-p` with ansible ... But not sure it that would mean just a mess of dependencies...
Author
Owner

Yeh, that makes sense. There was some talk of Terraform integration back in #106 (comment) but we didn't go down that route at the time.

It's not that much in the end https://docs.coopcloud.tech/operators/handbook/#how-do-i-bootstrap-a-server-for-running-co-op-cloud-apps 🤔

For the abra server new path...

I did try using cloud-init at some point and it wasn't too bad. If we had just those basic commands in the above docs available as another curl https://$SOMETHING.coopcloud.tech | bash and that was a one-liner, then we could include it? I know Hetzner supports this at least: https://community.hetzner.com/tutorials/basic-cloud-config

https://cloudinit.readthedocs.io/en/latest/

Trying to implement anything "fancy" inside the file is not worth it though. I wouldn't recommend it at all. But doing a simple Bash script should be fine...

This doesn't really help with the server add -p path though...

Yeh, that makes sense. There was some talk of Terraform integration back in https://git.coopcloud.tech/coop-cloud/organising/issues/106#issuecomment-9183 but we didn't go down that route at the time. It's not that much in the end https://docs.coopcloud.tech/operators/handbook/#how-do-i-bootstrap-a-server-for-running-co-op-cloud-apps 🤔 For the `abra server new` path... I did try using `cloud-init` at some point and it wasn't too bad. If we had just those basic commands in the above docs available as another `curl https://$SOMETHING.coopcloud.tech | bash` and that was a one-liner, then we could include it? I know Hetzner supports this at least: https://community.hetzner.com/tutorials/basic-cloud-config https://cloudinit.readthedocs.io/en/latest/ Trying to implement anything "fancy" inside the file is not worth it though. I wouldn't recommend it at all. But doing a *simple* Bash script should be fine... This doesn't really help with the `server add -p` path though...
Author
Owner

I think I'm gonna err on removing this for now. There are various conversations going on about how to address this but it seems most people think that abra probably isn't the best place to try and solve it. The next abra release won't be for some time, so hopefully we come up with a solution. If anyone has concerns, please let me know, can address comments here, even after this is closed.

I think I'm gonna err on removing this for now. There are various conversations going on about how to address this but it seems most people think that `abra` probably isn't the best place to try and solve it. The next `abra` release won't be for some time, so hopefully we come up with a solution. If anyone has concerns, please let me know, can address comments here, even after this is closed.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#389
No description provided.