Remove Docker provisioning logic? #389
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#389
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 inabra
. 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.
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...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 anothercurl 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-confighttps://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...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 nextabra
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.decentral1se referenced this issue from coop-cloud/abra2023-01-26 11:19:20 +00:00
decentral1se referenced this issue from coop-cloud/abra2023-01-31 20:43:01 +00:00