Open xmnlab opened 1 year ago
@esloch @luabida @EverVino do you have any opinions about that?
maybe it would be like reinventing the wheel, because current there is docker swarm and kubernetes for orchestration ... but the idea would be to keep thing really simple and focus on devs that don't need a very grained configuration
The idea looks good, but it seems complicated as well. Have you think to have this separated I mean containers management and containers and deployment management? sugar and sugar plus?
from the user perspective, I think it would just increase the steps for doing that.
sugar is flexible and can be easily extended ... so basically we would need to add a new class maybe something like SugarDeployment
and add it to the list of plugins .. and it should work (kind of)
so we could run it with some command like sugar deploy
and in the configuration we could have something like this:
version: 1.0
compose-app: docker-compose
default:
group: {{ env.ENV }}
service-groups:
- name: group1
project-name: project1
compose-path: containers/tests/group1/compose.yaml
env-file: .env
services:
default:
- service1
- service3
available:
- name: service1
- name: service2
- name: service3
deployment: # or maybe deploy
host: blablabla.com
credentials:
user: {{ env.DEPLOY_USERNAME }}
pass: {{ env.DEPLOY_PASSWORD }}
work_dir: /opt/services/myproject
virtual-env:
type: conda
name: myproject
steps:
- sugar build
- sugar start
- makim containers.migrate
maybe this would be a configuration for an implementation using ansible ... not sure yet how it would look like if it would use something like k3d or nomad
also the env file could change ... so we would need to have something for .env file .. but not sure yet the best approach for that .. in order to be something scalable
does it make sense?
Yes, I got it. Cool
It would be great to add a new configuration into the configuration file for deployment. This option would be used to define configuration such as servers, credentials, paths, environment variables, etc in order to run the deployment we could use ansible as a backend. Maybe not the CLI but instead the ansible as a library, so probably we will have much more flexibility.