I tried a lot of possible combinations, all without success.....I guess I invested at least 40 hours in testing.
I have now deleted everything and wait until NextCloud releases documentation that explains what to do in a clear way that works.

from app_api.

The resulting Log File is about 60 MB (59944187 Jun 7 14:29 nc_appapi.log) and as I said it contains sensitive information. I am going to replace such sensitive information with dummy/fake information and then upload the log file

from app_api.

I uploaded the files again... both in a zip file

from app_api.

Sure, send it over at [email protected], I'll attach the files here. The issues might indicate that the app_api setup is not correct. Did it work before with image generation?

from app_api.

By the way, the reason why I couldn't attach any file in the comment seems to be related to Firefox.
I tried with Chromium and it works.......strange

from app_api.

1. Remove test-deploy(there is a button on a TestDeploy page) and remove docker-socket-proxy
2. Create in docker user define bridge(https://docs.docker.com/network/drivers/bridge/#differences-between-user-defined-bridges-and-the-default-bridge)
3. Create docker-socket-proxy and specify in the network the newly created bridge
4. Try TestDeploy after that

from app_api.

VerifyConnection button works in your case only for the reason that you specified "/var/run/docker.sock" in Host

I suggest to remove this daemon, deploy this container https://github.com/cloud-py-api/docker-socket-proxy and create daemon with Host: nextcloud-appapi-dsp:2375 after that.

After that "VerifyConnection" button will try to connect to nextcloud-appapi-dsp:2375 which will fail, I guess...

Something is resolving all those DNS names in your system to 84.170.215.125 - you need to find what is that.

from app_api.

Please provide the following in addition to the above:

1. The relevant section of server logs, last 10 minutes or the error entries (found at data/nextcloud.log inside nextcloud's directory)
2. The docker socket proxy's container logs
3. A screenshot of the Test Deploy page with the Developers console open. The Dev console can be opened by pressing F12 or Ctrl+Shift+I in the browser.

from app_api.

1. The NextCloud log file is little complicated. I have several clients (both Mobile, Windows, Linux...) connected with my NextCloud instance and since it is logging everything, last 10 minutes (even just 5) would be a huge file, which I need to "clean from sensitive information like user ids..."

2. I attached the docker socket proxy log.

3. Where is to find that page?

from app_api.

1. grep app_api data/nextcloud.log should be good enough
2. I can't see it for some reason although I received an email. Did you delete it by chance?
3. i. Go to /index.php/settings/admin/app_api
   ii. Click on "Test deploy" inside a dropdown menu for the docker socket proxy's daemon
   iii. Press F12
   iv. Click on "Start Deploy test"

from app_api.

Please find attache the log file

from app_api.

What do you exactly need from Developer Console?
There are a lot of tabs/Screens.....

from app_api.

The screenshot, hoping it contains the information you need

from app_api.

It looks like the attachments are missing for the log file and the screenshot.

What do you exactly need from Developer Console?

Sorry for the confusion. I'm looking for errors in the "Console" tab or the "Network" tab.

from app_api.

Maybe github doesn't accept .png and .gz files?

from app_api.

Seems to work for me. You can give it one more try by dragging the file in the text box or a link to the uploaded file elsewhere.

from app_api.

part 1/3

from app_api.

part 2/3

from app_api.

part 1/3

from app_api.

@architectonio Nice that you managed to get context chat running. Did you check if this was solved as well?

For the attachments, I only see text messages this side (part 1/3, ...). You can use pastebin and imgur to upload the logs and screenshots and then paste a link here if the issue still persists.

from app_api.

@kyteinsky
I just created a zip file to download from my server.
How can I send you the link (privately)?

from app_api.

@architectonio Nice that you managed to get context chat running. Did you check if this was solved as well?

It seems to work, however when I make a question in the NextCloud Context Chat,
after a while I get "Context Chat task for NextCloud Assistant has filed".

from app_api.

The same happens by trying to generate image like "Draw a red Rose in a brown pot" with "NC Assistant Generate Image".
"Assistant has filed" after about a minute

from app_api.

Check your mailbox!

from app_api.

@kyteinsky Any finding in the log file?

from app_api.

sorry again for the late reply.

The only relevant line in the log was:

The "134423 ms" part is interesting. Can you check the php timeout in your php.ini config and increase it if it is too low? A good value could be 1800 to 3000 seconds.

Also, I'd like to see the Test deploy modal. Please follow these steps to run a test deployment using AppAPI:

1. Go to "/index.php/settings/admin/app_api"
2. Create a deploy daemon if not done already (verify the connection here itself)
3. Click on "Test deploy" in the actions menu
4. Click on "Start deploy test"
5. Send a screenshot of the browser or modal when done.

from app_api.

Click on "Test deploy" in the actions menu

from app_api.

No worries. I have already tried with Test Deploy.
Below the screen shots.

from app_api.

And here the ExApp logs:

Started
INFO: Started server process [1]
INFO: Waiting for application startup.
TRACE: ASGI [1] Started scope={'type': 'lifespan', 'asgi': {'version': '3.0', 'spec_version': '2.0'}, 'state': {}}
TRACE: ASGI [1] Receive {'type': 'lifespan.startup'}
TRACE: ASGI [1] Send {'type': 'lifespan.startup.complete'}
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:23000 (Press CTRL+C to quit)
INFO: Shutting down
INFO: Waiting for application shutdown.
TRACE: ASGI [1] Receive {'type': 'lifespan.shutdown'}
TRACE: ASGI [1] Send {'type': 'lifespan.shutdown.complete'}
TRACE: ASGI [1] Completed
INFO: Application shutdown complete.
INFO: Finished server process [1]
Started
INFO: Started server process [1]
INFO: Waiting for application startup.
TRACE: ASGI [1] Started scope={'type': 'lifespan', 'asgi': {'version': '3.0', 'spec_version': '2.0'}, 'state': {}}
TRACE: ASGI [1] Receive {'type': 'lifespan.startup'}
TRACE: ASGI [1] Send {'type': 'lifespan.startup.complete'}
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:23000 (Press CTRL+C to quit)

from app_api.

Could be a network issue. Can you click on the deploy daemon (not on the 3 dots) and then on "Verify connection" ?

from app_api.

"Daemon connection successful"

from app_api.

This is what gives back "docker ps"
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8ef91dc5a85c ghcr.io/cloud-py-api/test-deploy-cuda:release "python3 main.py" 6 days ago Up 3 days (healthy) nc_app_test-deploy
6c441efca423 ghcr.io/nextcloud/context_chat_backend:2.1.1 "python3 main.py" 6 days ago Up 3 days nc_app_context_chat_backend
4d936805fe6e localai/localai:master-aio-gpu-nvidia-cuda-12 "/aio/entrypoint.sh" 12 days ago Up 3 days (healthy) 0.0.0.0:28890->8080/tcp, :::28890->8080/tcp local-ai
3d02fb1d6b04 ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release "/bin/bash start.sh" 2 weeks ago Up 3 days (healthy) 0.0.0.0:2375->2375/tcp, :::2375->2375/tcp nextcloud-appapi-dsp

from app_api.

Can you try to ping the ex-app's container (nc_app_test-deploy) from nextcloud's container?

The network configuration for the daemon might be wrong. Since you're using the AIO, network should be nextcloud-aio.

from app_api.

We need 3 results from the docker inspect command, for Nextcloud(as it is in a container), DockerSocketProxyContainer and for TestDeploy container.

from app_api.

The "NoScript" extension was the cause.
Even the whole github is allowed to run JS, " …github-production-user-asset-6210df.s3.amazonaws.com" was still "Not Allowed".

Test:

from app_api.

We need 3 results from the docker inspect command, for Nextcloud(as it is in a container), DockerSocketProxyContainer and for TestDeploy container.

Here you go.
NextCloud isn't running in a Docker Container.
dockerinspect-testdeploy.txt
dockerinspect-socket.txt

from app_api.

And this is the docker inspect of "Context Chat Backend" which is also not working
dockerinspect-contextchatbackend.txt

from app_api.

I guess this is a reason: "NetworkMode": "bridge"

Ok, we need to move those Note about bridge from here: https://cloud-py-api.github.io/app_api/DeployConfigurations.html

to somewhere else to be more visible...

from app_api.

Can you try to ping the ex-app's container (nc_app_test-deploy) from nextcloud's container?

The network configuration for the daemon might be wrong. Since you're using the AIO, network should be nextcloud-aio.

OK, I am going to figure out what and how create such Network and then, I guess, re-deploy the containers

from app_api.

1. Remove test-deploy(there is a button on a TestDeploy page) and remove docker-socket-proxy

   2. Create in docker user define bridge(https://docs.docker.com/network/drivers/bridge/#differences-between-user-defined-bridges-and-the-default-bridge)

   3. Create docker-socket-proxy and specify in the network the newly created bridge

   4. Try TestDeploy after that

Done.
However Test Deploy is stucking on Heartbeat

from app_api.

and the docker-socket-proxy isn't longer listed with a "docker ps", just disappeared

from app_api.

after restarting docker daemon "dsp" is back

from app_api.

And here the result of the new "docker inspect ......"
dockerinspect-testdeploy.txt
dockerinspect-socket.txt

from app_api.

ping host(or where the Nextcloud is):

ping test-deploy
ping nextcloud-appapi-dsp

both containers(nc_app_test-deploy and dsp one) should be running

This is how to diagnose DNS resolving problem

from app_api.

Seems that both aren't reachable....

ping test-deploy
PING test-deploy.architectonio.net (84.170.215.125) 56(84) bytes of data.
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=1 ttl=63 time=0.629 ms
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=2 ttl=63 time=0.998 ms
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=3 ttl=63 time=1.16 ms
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=4 ttl=63 time=1.17 ms
^C

ping nextcloud-appapi-dsp
PING nextcloud-appapi-dsp.architectonio.net (84.170.215.125) 56(84) bytes of data.
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=1 ttl=63 time=1.22 ms
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=2 ttl=63 time=0.997 ms
64 bytes from 84.170.215.125 (84.170.215.125): icmp_seq=3 ttl=63 time=0.920 ms
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=4 ttl=63 time=0.879 ms
64 bytes from p54aad77d.dip0.t-ipconnect.de (84.170.215.125): icmp_seq=5 ttl=63 time=0.929 ms
^C

from app_api.

This is what AppAPI does on a heartbeat step during TestDeploy(only in HTTP mode, in HTTPS with remote installation also is another one):

curl 'http://test-deploy:23000/heartbeat'

You can get port from oc_ex_apps table or just try with 23000, 23001, 23002 or 23003 - in most cases it will one of these ports

from app_api.

from last testdeploy inspect:

            "Networks": {
                "nextcloud-aio": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": [
                        "test-deploy",
                        "9b7f1cbb4b6c"
                    ],
                    "NetworkID": "5d26f704ae6c26bd2eb55e8b2389b040d36c19caec5e392e47732d9f795c9e64",
                    "EndpointID": "05e265f32d302232be1e01bffc654c5cdcad18ebdb7259cf49f173f6719d0a1d",
                    "Gateway": "172.19.0.1",
                    "IPAddress": "172.19.0.2",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:13:00:02",
                    "DriverOpts": null
                }
            }
        }

docker-socket-proxy inspect:

            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "3e828587134e852ff76006e8bbbc8281a930a6fc5ccb68312785928323bc4362",
                    "EndpointID": "3da0893301b8df218df541f86ce7f6832e629d7ecf9b1375d25d52d2d86b3a8b",
                    "Gateway": "172.17.0.1",
                    "IPAddress": "172.17.0.8",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:11:00:08",
                    "DriverOpts": null
                }
            }

from app_api.

This is what AppAPI does on a heartbeat step during TestDeploy(only in HTTP mode, in HTTPS with remote installation also is another one):

curl 'http://test-deploy:23000/heartbeat'

You can get port from oc_ex_apps table or just try with 23000, 23001, 23002 or 23003 - in most cases it will one of these ports

No answer on all ports
Regarding oc_ex_apps, I do not know what it is at all... :-(

from app_api.

Screenshot of from NextCloud Interface

from app_api.

VerifyConnection button works in your case only for the reason that you specified "/var/run/docker.sock" in Host

I suggest to remove this daemon, deploy this container https://github.com/cloud-py-api/docker-socket-proxy and create daemon with Host: nextcloud-appapi-dsp:2375 after that.

After that "VerifyConnection" button will try to connect to nextcloud-appapi-dsp:2375 which will fail, I guess...

Something is resolving all those DNS names in your system to 84.170.215.125 - you need to find what is that.

OK, I'll do as you suggested, but on Sunday in the late afternoon. Now I have to travel a little....

from app_api.

Something is resolving all those DNS names in your system to 84.170.215.125 - you need to find what is that.

This is the Public IP Address I got (for today) by my ISP, on which points my domain

from app_api.

This is the Public IP Address I got (for today) by my ISP, on which points my domain

I understand that, but that DNS names should be resolved to the local addresses(docker should do that) and not your public address.
They can be resolved to your public address only when "network=host" is set up, which should not be done for this type of setup(when Nextcloud and ExApps are on the same host).

from app_api.

VerifyConnection button works in your case only for the reason that you specified "/var/run/docker.sock" in Host

I suggest to remove this daemon, deploy this container https://github.com/cloud-py-api/docker-socket-proxy and create daemon with Host: nextcloud-appapi-dsp:2375 after that.

After that "VerifyConnection" button will try to connect to nextcloud-appapi-dsp:2375 which will fail, I guess...

Something is resolving all those DNS names in your system to 84.170.215.125 - you need to find what is that.

I created the network "nextcloud-aio"
and this is what a "docker inspect" gives back

docker network inspect nextcloud-aio

[
    {
        "Name": "nextcloud-aio",
        "Id": "5d26f704ae6c26bd2eb55e8b2389b040d36c19caec5e392e47732d9f795c9e64",
        "Created": "2024-06-14T10:08:31.757855622+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.19.0.0/16",
                    "Gateway": "172.19.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

I removed the daemon and redeployed as "nextcloud-appapi-dsp:2375".

"docker ps" shows it up and running

3d02fb1d6b04   ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release   "/bin/bash start.sh"     2 weeks ago   Up 18 minutes (healthy)   0.0.0.0:2375->2375/tcp, :::2375->2375/tcp     nextcloud-appapi-dsp

A "nmap nextcloud-appapi-dsp -p2375" gives back:

PORT     STATE    SERVICE
2375/tcp filtered docker

And a ping shows my (currently) public IP Address
"ping nextcloud-appapi-dsp"

PING nextcloud-appapi-dsp.architectonio.net (93.224.198.141) 56(84) bytes of data.
64 bytes from p5de0c68d.dip0.t-ipconnect.de (93.224.198.141): icmp_seq=1 ttl=63 time=1.29 ms
64 bytes from p5de0c68d.dip0.t-ipconnect.de (93.224.198.141): icmp_seq=2 ttl=63 time=1.86 ms
^C64 bytes from 93.224.198.141: icmp_seq=3 ttl=63 time=1.28 ms

And NextCloud ExtApp Dashboard shows: "All ExApps are up-to-date. Default Deploy daemon is not accessible "

I do not know is something is wrong on my Server Network Configuration, however everything else just runs smoothly, without any noticeable issue.

from app_api.

What I also noticed is the fact that both "Test Deploy" and "Context Chat Backend" containers have no port exposed while all other containers are exposing a port.
It is so OK?

docker ps
05fb1eb96a0b ghcr.io/nextcloud/context_chat_backend:2.1.1 "python3 main.py" About an hour ago Up 17 seconds nc_app_context_chat_backend
c35572f9cd25 ghcr.io/cloud-py-api/test-deploy-cuda:release "python3 main.py" 11 hours ago Up 18 seconds (healthy) nc_app_test-deploy
c9ded5aa33ae ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release "/bin/bash start.sh" 12 hours ago Up 11 seconds (healthy) 0.0.0.0:2375->2375/tcp, :::2375->2375/tcp nextcloud-appapi-dsp
4d936805fe6e localai/localai:master-aio-gpu-nvidia-cuda-12 "/aio/entrypoint.sh" 2 weeks ago Up 14 seconds (health: starting) 0.0.0.0:28890->8080/tcp, :::28890->8080/tcp local-ai
1b3b3efb8d7f collabora/code "/start-collabora-on…" 2 weeks ago Up 18 seconds 0.0.0.0:9980->9980/tcp, :::9980->9980/tcp collabora-code

Another point I do not really catch is the "nextcloud-aio" network.
I created it and associated to the "Docker Socket Proxy" Container, however it is to me not clear why I cannot use another docker bridged network, since my Nextcloud Installation isn't an AIO but a bare installation and all other containers, including COLLABORA-CODE and LOCAL-AI works very well.

from app_api.

Any news on this?

from app_api.

I guess this is a reason: "NetworkMode": "bridge"

Ok, we need to move those Note about bridge from here: https://cloud-py-api.github.io/app_api/DeployConfigurations.html

to somewhere else to be more visible...

Am I reading this correctly that the docker socket proxy cannot be on a remote host? Test deploy seems to fail for me, much as the original post here, because it cannot resolve the name http//:test-deploy:23000

from app_api.

I don't know if DSP must run on the local host, however my DSP runs on the local host and I tried with "host", "bridge" and also "nextcloud-aio". The issue remains the same, "Test Deploy" and "Context Chat Backend" are deployed but not reachable.
I also noticed that "Context Chat Backend" restarts every few seconds (by observing the results of "watch -n 0.5 docker ps" ).

from app_api.

@architectonio

Another point I do not really catch is the "nextcloud-aio" network.

It was mentioned as the assumption that you are using Nextcloud AIO - which has this custom network created for the AIO containers.

I don't know if DSP must run on the local host

The purpose of the DSP - is to provide a secure access for AppAPI to docker via network, it can be local or remote.

I also noticed that "Context Chat Backend" restarts every few seconds (by observing the results of "watch -n 0.5 docker ps" ).

Is there any logs or error that can give us a hint? Is there any errors related in system logs from docker (journalctl -u docker) or from Context Chat Backend container?

For now I can't say more that was said before on how to investigate networking issues, since the daemon connection is fine and the deployment working, the issue is only in communication part between ExApp and NC, which is likely some specifics of certain system setup. I'll back to you as soon as find something.

from app_api.

from app_api.

@andrey18106
@andrey18106
Thank you for your reply, I mentioned earlier that I do not use and never have used NextCloud AIO. My installation is on the Server (Debian, with MariaDB, Apache, PHP and so on).

Is there any logs or error that can give us a hint? Is there any errors related in system logs from docker (journalctl -u docker) or from Context Chat Backend container?

As I wrote before, docker works perfectly, with no network or other issue.
I currently have about ten applications on docker including LocalAI (CUDA), Collabora CODE, Home Assistant, Libretranslate, SearxNG, and so on.

A "docker ps" gives back:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
123456789012 ghcr.io/cloud-py-api/test-deploy-cuda:release "python3 main.py" 45 seconds ago Up 43 seconds (healthy) nc_app_test-deploy
1234567890ab localai/localai:master-aio-gpu-nvidia-cuda-12 "/aio/entrypoint.sh" 4 days ago Up 4 days (healthy) 0.0.0.0:28890->8080/tcp, :::28890->8080/tcp local-ai
1234567890cd ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release "/bin/bash start.sh" 4 days ago Up 4 days (healthy) 0.0.0.0:2375->2375/tcp, :::2375->2375/tcp nextcloud-appapi-dsp
...................................

Notice that the Test Deploy has no network or port

Here the "docker network list"
NETWORK ID NAME DRIVER SCOPE
a9421922f6d8 bridge bridge local
371bcd681096 host host local
c92d51732e32 localai-webui_default bridge local
5d26f704ae6c nextcloud-aio bridge local
62ccc5fcbaa2 none null local

from app_api.

This is the running DSP (I removed Test-Deploy and Context_Chat Backend) which is reachable

ExApps installed: 0
Name: docker_socket_proxy
Protocol: http
Host: 127.0.0.1:2375
Deploy config
Docker network: bridge
Nextcloud URL: https://nextcloud.mydomain.net
HaProxy password: 12345678
GPUs support: true
Compute device: CUDA (NVIDIA

from app_api.

I think they suggested not to use bridge because bridge won't look things up by container name. I set mine to master_default, but no difference in the behavior.

from app_api.

Same issue here. I have NC running in a VM (direct install, no docker). And I have docker for running this ExApp stuff.

The daemon connection test is successful but the deployment test fails after a long time during the heartbeat check.

No idea what else to try.

from app_api.

Same issue here. I have NC running in a VM (direct install, no docker). And I have docker for running this ExApp stuff.

The daemon connection test is successful but the deployment test fails after a long time during the heartbeat check.

No idea what else to try.

I had exactly the same issue.

from app_api.

Same issue here. I have NC running in a VM (direct install, no docker). And I have docker for running this ExApp stuff.

The daemon connection test is successful but the deployment test fails after a long time during the heartbeat check.

No idea what else to try.

Please create a separate issue with describing of your configuration.
Without NC logs, container info/logs and information about setup we can't do much.

I had exactly the same issue.

Have you tried with the latest version 3.1.0 (where we fixed a critical bug with APCu), heartbeat still didn't work?

If you tried and it still didn't work, as an option I can offer if you have the opportunity to give VPN access to the test environment where you can't do it, and we'll try to figure out what the reason might be.

But with version 3.1.0 everything has already worked for most people, I hope that we can help you too.

from app_api.

I had exactly the same issue.

Have you tried with the latest version 3.1.0 (where we fixed a critical bug with APCu), heartbeat still didn't work?

If you tried and it still didn't work, as an option I can offer if you have the opportunity to give VPN access to the test environment where you can't do it, and we'll try to figure out what the reason might be.

But with version 3.1.0 everything has already worked for most people, I hope that we can help you too.

Yes I have tried with the latest version 3.1.0, however I just used the already deployed Docker Socket Proxy and I do not know if it affects in any way the AppAPI.
Tomorrow I am going to re-deploy the DSP and watch what happens.

Would be worth deleting the NextCloud Assistant, NextCloud Assistant Context Chat nad AppAPI and then reinstall again?

from app_api.

But with version 3.1.0 everything has already worked for most people, I hope that we can help you too.

Yes, I'm on 3.1.0 (I also updated NC to 29.0.8).

One thing I noticed is that the nextcloud-appapi-dsp container becomes unhealthy relatively quickly. Not sure, if this has anything to do with the issue? (I downloaded the most recent image and updated the container but it still becomes unhealthy a minute after starting or so)

from app_api.

You have a docker-socket-proxy address where it is listens.

Look in the DB which port is assigned to the test-deploy application in the oc_ex_apps table.

Try to do curl 'http://{docker-socket-proxy-address}:{test-deploy-port}/heartbeat' from the Nextcloud instance.

If you use https you need to add authentification for request with -u app_api_haproxy_user:{your_haproxy_password}

This is literally what AppAPI does on heartbeat.

To not this issue longer(it is already 65+ messages) - please create a separate issue with posted configs.

from app_api.

You have a docker-socket-proxy address where it is listens.

Look in the DB which port is assigned to the test-deploy application in the oc_ex_apps table.

Try to do curl 'http://{docker-socket-proxy-address}:{test-deploy-port}/heartbeat' from the Nextcloud instance.

If you use https you need to add authentification for request with -u app_api_haproxy_user:{your_haproxy_password}

This is literally what AppAPI does on heartbeat.

To not this issue longer(it is already 65+ messages) - please create a separate issue with posted configs.

This is what i get with https: curl https://127.0.0.1:2375/ -u app_api_haproxyuser:mytestpassword
curl: (35) OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version number

And this with http: curl http://127.0.0.1:2375/ -u app_api_haproxyuser:mytestpassword
**

401 Unauthorized

The DSP was deployed in this way:
docker run -v /var/run/docker.sock:/var/run/docker.sock -e NC_HAPROXY_PASSWORD="mytestpassword" --restart always --name nextcloud-appapi-dsp -h nextcloud-appapi-dsp --net nextcloud-aio -p 2375:2375 --privileged -d ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release

A docker ps shows:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c011616e7873 ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release "/bin/bash start.sh" 6 minutes ago Up 6 minutes (healthy) 0.0.0.0:2375->2375/tcp, :::2375->2375/tcp nextcloud-appapi-dsp

from app_api.

@architectonio Please correct the name of the user to app_api_haproxy_user and try again. Note: for HTTPS Docker Socket Proxy you can't use 127.0.0.1 host, in your case the error for https additionally means that the Docker Socket Proxy wasn't set up with SSL enabled (it enables if /certs/cert.pem is mounted in container during startup).

from app_api.

curl http://127.0.0.1:2375/ -u app_api_haproxy_user:mytestpassword

403 Forbidden

from app_api.

curl http://127.0.0.1:2375/ -u app_api_haproxy_user:mytestpassword

403 Forbidden

Request forbidden by administrative rules.

There is no route in your request, it's not allowed, so the response is correct, and auth is passed.

from app_api.

I assume this means that the AppAPI and everything that is deployed should work...

from app_api.

Unfortunately the issue persists.
Both "Context Chat Backend" and "Test Deploy" Apps, stuck by Healthchecking.

A docker ps shows:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
110c19421d84 ghcr.io/nextcloud/context_chat_backend:2.2.1 "python3 main.py" About a minute ago Up About a minute nc_app_context_chat_backend
cf74179d5b31 ghcr.io/cloud-py-api/test-deploy:release-cuda "python3 main.py" 8 minutes ago Up 7 minutes (healthy) nc_app_test-deploy

And Nextcloud "You Apps" Dashboard shows both Apps with a Healtchecking loop.

from app_api.