docky init simplification

[sebastienbeau]

Hi

I would like to simplify docky init. It should only generate the ".env" file and nothing more.

As docky can be use by whatever project (I use for node and ruby). I prefers to keep it simple as possible.

If we want to generate a new project I prefer to use directly copier (we do not create a lot of projet). And copier is not something hard to use and it also good to know how to use it, as sometime you need to launch a copy update on existing OCA Repo

@bealdav @PierrickBrun @hparfr

This will solve the publication of docky on pipy and also unblock the docky-template

[rvalyi]

Hello I would also recommend looking at how does Doodba bootstrap new projects as well because they do lot's of things pretty well too, I'll try to look today...

[rvalyi]

so Doodba does it all with copier https://github.com/Tecnativa/doodba-copier-template specially https://github.com/Tecnativa/doodba-copier-template/blob/main/copier.yml so I would say +1 for bootstraping with copier only, unless I'm missing something.

[bealdav]

If you want simplify, please remove secrets.docker-compose.yml Env vars are sufficient to pass secrets. env comes from .env file or real env vars : really efficient. Only infra knows secrets and populate env vars, that's nice as it

[PierrickBrun]

I agree, this would simplify a lot of things just for a copier command. Also, about the naming, it is weird to have docky do things other than docker/docker-compose

We could name our fork of copier copiy :smile:

[bealdav]

or copipy ?

[hparfr]

As docky can be use by whatever project (I use for node and ruby). I prefers to keep it simple as possible. What do you want to simplify ? The code or the UX ?

So let's define the objectives of the project. Who is it for? What it should do ? What techno it should support (podman, docker compose v2) ? etc.

Then we will know what to put in the scope.

[sebastienbeau]

For me

The objectif of docky is to have a make simplier the use of docker-compose

• default service
• only useful cmd
• docky open that work with docky run
• create volume with working access right
• configure .env
• ... (every specific docker stuff) So dev don't have to waste time and fix stuff by themself.

It can be use for Odoo of whatever project, but project that respect the docky logic: "The container should start with root so we can switch to root or specific user using gosu" (or we should find an other way to simply have the possibility to enter as root or no root)

We can replace docky by a big list of alias on top of docker-compose but it will be complex bash code.

For podman as there is not "docker-compose" like project I prefer to continue with docker- compose and so we should move to docker-compose 2. (We can add it in the roadmap).

But indeed we need to take time to define and explain in the readme the aim and roadmap. I can start a PR with the "Who is it for? What it should do ? What techno" in the readme ?

[sebastienbeau]

Note: I am not close-mind I see that PR : https://github.com/akretion/docky/pull/150 So maybe some of you want to have more feature in docky, so I am open to discuss about it (we need to take time for discussing on the roadmap)

In any case, if we want to conserve the templating stuff, I think we should improve the command and having something like

docky project init => create .env file (after a git clone of an existing project) docky project create => copier copy ... docky project update => copier update

So I propose 1 - remove copier stuff and simplify docky init (so pipy deploy will be fixed) 2 - open discussion on the roadmap and the perimeter of docky (put it in the readme) 3 - reimplement copier stuff if need but with pipy compatibility

[sebastienbeau]

change have been done here : https://github.com/akretion/docky/pull/154

[rvalyi]

just to make it clear: to test it:

copier copy gh:akretion/docky-odoo-template odoo16
cd odoo16
docky init
DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 docky run

(yes I needed to set DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 for the build to work since it needs the buildkit feature)

[hparfr]

IMO:

Who is it for : Docky is first designed for us, Akretion devs, to be reduce the coginitve load for working on odoo projects on our infrastructures (dev, ci, prod).

What is it used for: Docky should stay a wrapper around other tools in order to simplify /shorten what we do often :

• start a dev environment docky run
• open a running container docky open
• start a prod environment docky up (should we really need docky in prod ?)

And less often, but because is rarely done, having a simple way of doing multiple steps is good:

• scaffold a project
• initialize a remote env

Docky is not mandatory; it's just a wrapper around some other tools. Docky is about infrastructure pip install git+https://github.com/akretion/docky is good enough, no need to publish on pypi. Docky is for statefull applications Is it just of dev? or for prod ? or for ci ? don't know.

More details about commands:

Easy, no changes docky build shortcut to docker-compose build docky logs shortcut to docker-compose logs -f --tail 200 docky up shortcut to mkdir some volumes then docker-compose up -d

More nuanced: docky run shortcut to mkdir some volumes then docker-compose kill && docker-compose run --service-ports --rm odoo gosu odoo bash

--service ports is only needed in prod. it can be (in dev it's useless because of traefik)

I'm not sure our approach is good here. We use this interactive work inside with starting with bash because our images are too long to start. docker-compose restart odoo looks simplier and more effective.

docky kill shortcut to docker-compose kill in parallel is parallel still needed today?

docky open very hacky. we may replace it withdocker exec -it odoo bash

About rare tasks:

docky init boostrap a project and update the project layout

Benefits:

• do not learn copier commands.
• project template url already provided
• inject some stuff into copier (like uid)

docky remote init prepare a project in a remote environment: (not merged yet)

• manage gitlab credentials
• clone the project
• take care of db credentials

Benefits:

• take care of gitlab related stuff (create a deploy key, git clone the project)

docky remote logs display logs of the remote instance (prod ? ci?) (not implemented yet)

Benefits:

• shorter to type

docky remote deploy deploy a new version (prod) (not implemented yet) shortcut for

• log into the server, (ssh, cd )
• fetch last build (git pull, docker pull)
• restart container (kill && up)

Benefits:

• hide complexity
• ensure all projects are deployed in the same way

[bealdav]

Thanks @hparfr for this full time consuming analyze. Reading this I suppose we could replace docky by alias or abbreviation

[rvalyi]

Just a remark: I think an important use case is also to give our IT literate customers an easy way to get a dev replica of their project up and running. In many cases it's also a condition for them to trust us and our hosting. In this case they won't need the init command. But having docky easy to install and look standard may help.

[PierrickBrun]

I agree with @bealdav

Maybe the easiest path is to simplify docky enough to be able to replace it with a properly documented bash file with only aliases defined inside.

That way you can either install the file directly in your bash_aliases or you can read the online version and paste the command you need.

The we can restrict the docky python code to more complex tasks like docky init.

[bealdav]

Not than abbreviation in fish shell are really more powerful than alias in bash because it replace shortcut by real cmd including resolving var eval. https://fishshell.com/docs/current/cmds/abbr.html

[hparfr]

Update to my previous message:

Who is it for : Docky is first designed for us, Akretion devs, to be reduce the coginitve load for working on odoo projects on our infrastructures (dev, ci, prod).

Still true.

What is it used for: Docky should stay a wrapper around other tools in order to simplify /shorten what we do often :

start a dev environment docky run open a running container docky open start a prod environment docky up (should we really need docky in prod ?)

Docky in prod is not an hard requirement, the command used in prod are:

• docky pull == docker compose pull
• docky up == docker compose up -d
• docky down == docker compose down and docky open ~= docker compose exec odoo gosu odoo bash

And less often, but because is rarely done, having a simple way of doing multiple steps is good:

scaffold a project initialize a remote env

It think now, we should put these two features (scaffolding & initialization) in another tool.

Docky is not mandatory; it's just a wrapper around some other tools. Docky is about infrastructure

Still true

pip install git+https://github.com/akretion/docky is good enough, no need to publish on pypi.

Still true

Docky is for statefull applications Is it just of dev? or for prod ? or for ci ? don't know.

For the moment, we don't use it on CI.

More details about commands: docky up shortcut to mkdir some volumes then docker-compose up -d Not needed anymore with create_host_path

More nuanced: docky run shortcut to mkdir some volumes then docker-compose kill && docker-compose run --service-ports --rm odoo > gosu odoo bash --service ports is only needed in prod. it can be (in dev it's useless because of traefik) Still true

docky init boostrap a project and update the project layout I think now it should be done elsewhere

docky remote init prepare a project in a remote environment: (not merged yet) Like above

docky remote deploy deploy a new version (prod) (not implemented yet) We are not here yet. Tools may change.