Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Podman support #727

Open
Herohtar opened this issue Jun 15, 2023 · 15 comments
Open

Podman support #727

Herohtar opened this issue Jun 15, 2023 · 15 comments

Comments

@Herohtar
Copy link
Contributor

Herohtar commented Jun 15, 2023

#139 was closed with a comment saying that CLI 1.x now works with podman, but it does not appear to be true. I get the following output when running nhost up:

Setting up Nhost development environment...
Starting Nhost development environment...
Error: unknown flag: --project-directory
See 'podman --help'
failed to start Nhost development environment: failed to start docker compose: exit status 125

As I understand it, podman itself can work with docker-compose, but it appears that the CLI is running the docker compose ... command rather than docker-compose. That means it gets passed to podman via podman-docker, and the compose command is not supported by podman:

$ docker compose
Error: unrecognized command `podman compose`
Try 'podman --help' for more information

Indeed, if I run docker compose --project-directory ... I get the same output as the CLI, which seems to confirm the cause of the error during nhost up:

Error: unknown flag: --project-directory
See 'podman --help
@dbarrosop
Copy link
Member

dbarrosop commented Jun 15, 2023

Could you try if installing podman-compose fixes it?

@Herohtar
Copy link
Contributor Author

I already have podman-compose installed. It does not make a difference because podman-compose is a separate script/tool and does not add a compose command to podman (ie, podman compose is still invalid)

@dbarrosop
Copy link
Member

Would you mind testing one of the artifacts from here? (scroll to the bottom)

https://github.com/nhost/cli/actions/runs/5287387814?pr=729

@Herohtar
Copy link
Contributor Author

$ cli up
Setting up Nhost development environment...
Starting Nhost development environment...
podman-compose version: 1.0.6
usage: podman-compose [-h] [-v] [--in-pod in_pod] [--pod-args pod_args]
                      [--env-file env_file] [-f file] [-p PROJECT_NAME]
                      [--podman-path PODMAN_PATH] [--podman-args args]
                      [--podman-pull-args args] [--podman-push-args args]
                      [--podman-build-args args] [--podman-inspect-args args]
                      [--podman-run-args args] [--podman-start-args args]
                      [--podman-stop-args args] [--podman-rm-args args]
                      [--podman-volume-args args] [--no-ansi] [--no-cleanup]
                      [--dry-run]
                      {help,version,wait,systemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs,config,port,pause,unpause,kill}
                      ...
podman-compose: error: argument command: invalid choice: '/nhost-test' (choose from 'help', 'version', 'wait', 'systemd', 'pull', 'push', 'build', 'up', 'down', 'ps', 'run', 'exec', 'start', 'stop', 'restart', 'logs', 'config', 'port', 'pause', 'unpause', 'kill')
failed to start Nhost development environment: failed to start docker compose: exit status 2

@dbarrosop
Copy link
Member

Apologies for the late response. It is unfortunate that podman-compose isn't compatible with docker-compose. I guess the easiest thing to do would be to fallback to docker-compose with podman. Thoughts?

@Herohtar
Copy link
Contributor Author

I believe Podman officially supports docker-compose, so going through that should be fine.

@awidjaja
Copy link

I believe Podman officially supports docker-compose, so going through that should be fine.

Installing docker-compose doesn't solve the issue because it is already deprecated by docker.
Docker expect a separate plugin (docker-cli-compose) installed and then it will be used by the docker compose. command.

The need here is to launch nhost containers locally using podman - so nhost up command should detect if podman-compose is installed and use it instead. A better option for podman is to also provide the kubernetes yaml format because podman can launch containers inside a pod using podman play kube command.

@dbarrosop
Copy link
Member

so nhost up command should detect if podman-compose is installed and use it instead.

The problem is that podman-compose isn't compatible with docker-compose so it requires an extra effort to handle. While this may be fine, this isn't a priority for us right now. If someone wants to contribute it that'd be great though.

@awidjaja
Copy link

May I know what argument was use in your test above for podman-compose?

According to this article, podman-compose is compatible with docker-compose.yml without any change.

podman-compose up -d -f .nhost/docker-compose.yml

@Herohtar
Copy link
Contributor Author

I think the issue is that the Docker command compose (docker compose, which is not docker-compose) has some flags that aren't supported by podman-compose. The test simply changed the command to run podman-compose without changing any of the arguments.

@dbarrosop
Copy link
Member

The test simply changed the command to run podman-compose without changing any of the arguments

Correct, it was just a dummy change to see if it would work. You can see it here + the needed arguments here:

https://github.com/nhost/cli/pull/729/files

@awidjaja
Copy link

Thanks both for clarifying. It's an issue with the --project-directory cli parameter that is not used in podman-compose.

According to this docker compose cli reference, that parameter is for specific case where multiple docker-compose.yml files that reside is different directories. In my understanding, nhost generate only a single docker-compose.yml file inside .nhost sub-directory.

My suggestion on how to make it work for podman-compose:

Use docker version command to check whether podman is used, and in that case use podman-compose up instead of docker compose up without the --project-directory argument , instead include the working directory in the -f argument. (in the test example, change from: dc.filepath to dc.workingDir+"/"+dc.filepath

$ docker version
Client:       Podman Engine
Version:      4.5.1
API Version:  4.5.1
Go Version:   go1.18.10
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64

Server:       Podman Engine
Version:      4.5.0
API Version:  4.5.0
Go Version:   go1.19.7
Built:        Fri Apr 14 15:42:56 2023
OS/Arch:      linux/amd64

# or alternatively use `which podman-compose` to check if it's installed.

$ which podman-compose
/usr/local/bin/podman-compose

# Result of nhost up for docker compose
docker compose up -f ~/.nhost/docker-compose.yml

# Result of nhost up for podman
podman-compose up -f ~/.nhost/docker-compose.yml

@dbarrosop
Copy link
Member

dbarrosop commented Jul 25, 2023

Removing --project-directory isn't as simple as just changing the path to the compose file, it has an implication on mounted volumes so those would most likely to be fixed which might not be as trivial. For instance:

$ docker compose -f .nhost/docker-compose.yaml up
[+] Running 3/0
 ✔ Network nhost_default                  Created                                                                                                                                                                          0.0s
 ✔ Volume "nhost_root_node_modules"       Created                                                                                                                                                                          0.0s
 ✔ Volume "nhost_functions_node_modules"  Created                                                                                                                                                                          0.0s
 ⠋ Container nhost-minio-1                Creating                                                                                                                                                                         0.0s
 ⠋ Container nhost-dashboard-1            Creating                                                                                                                                                                         0.0s
 ⠋ Container nhost-mailhog-1              Creating                                                                                                                                                                         0.0s
 ⠋ Container nhost-functions-1            Creating                                                                                                                                                                         0.0s
 ⠋ Container nhost-postgres-1             Creating                                                                                                                                                                         0.0s
 ⠋ Container nhost-traefik-1              Creating                                                                                                                                                                         0.0s
Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /Users/dbarroso/workspace/project/.nhost/.nhost/data/nogit/minio

Notice .nhost/.nhost. With --project-directory instead the path points correctly to /Users/dbarroso/workspace/project/.nhost/data/nogit/minio. I think the issue is that -f changes the working directory while --project-directory doesn't.

@jnv
Copy link

jnv commented Jan 11, 2024

I'm just trying out nhost CLI with Podman to see if I can get it to fly. From what I observed, podman aliased to docker will attempt to launch docker-compose if it's available. (On Fedora the original Python-based docker-compose is available from repositories.)

$ docker compose
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Run compose workloads via an external provider such as docker-compose or podman-compose

Description:
  This command is a thin wrapper around an external compose provider such as docker-compose or podman-compose.  This means that podman compose is executing another tool that implements the compose functionality but sets up the environment in a way to let the compose provider communicate transparently with the local Podman socket.  The specified options as well the command and argument are passed directly to the compose provider.

The default compose providers are docker-compose and podman-compose.  If installed, docker-compose takes precedence since it is the original implementation of the Compose specification and is widely used on the supported platforms (i.e., Linux, Mac OS, Windows).

If you want to change the default behavior or have a custom installation path for your provider of choice, please change the compose_provider field in containers.conf(5).  You may also set PODMAN_COMPOSE_PROVIDER environment variable.

Usage:
  podman compose [options]

Examples:
  podman compose -f nginx.yaml up --detach
  podman --log-level=debug compose -f many-images.yaml pull

>>>> Executing external compose provider "/usr/bin/docker-compose". Please refer to the documentation for details. <<<<

I can set DOCKER_HOST to Podman's socket to work with docker-compose. nhost up still fails since the legacy docker-compose doesn't support --wait for change, but when I drop it, the following works with Podman:

$ export DOCKER_HOST=unix://run/user/1000/podman/podman.sock
$ docker-compose --project-directory /path/to/nhost/project -f .nhost/docker-compose.yaml -p nhost-project-name up -d

There's a request for support of --project-directory in podman-compose, so I guess it'd be the best to fix it there.

Copy link

stale bot commented Jul 9, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jul 9, 2024
@dbarrosop dbarrosop removed the stale label Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants