Portainer created container not visible in docker

[Shadow]

If it helps, here is living proof that a Linux VM with Docker works great on my NAS: Installing MailCow on Synology NAS

 

[Micky]

What? You are running Linux in a VM settled on a Synology DS and inside you are running one or more Docker containers?
This setup is way to complicated for me and maybe wastes too much RAM and CPU cycles, isn't it?

 

[one-eyed-king]

VMM actualy uses KVM and QEMU under the hood, so even though there will be a footpint in regards of marshelling io/cpu from host to vm and other way arround, I believe it is still relativly small compared to other hypervisor solution. I have no idea if the RAM is allocated up front or dynamicly during run time - so this could be a huge issue for systems with low memory. What actual makes up the solution is for the vm to run an os with a kernel that does not suffer the proplem the DSM's kernel's do. Of course this won't be remotely close to be as efficient as containers are.

Though, the main question is: would you rather trade a raised ressources demand for a reliable operation of your containers (and get rid of other nasty limitations of Synologies docker package) or would you rather stay with a ressource saving solution that just doesn't work stable? If you use real nfs volumes, you can still store the data directly on the NAS and can switch easily back to using the build-in docker when DSM7 has proven to be shipped with a fixed kernel.

 

[Shadow]

What? You are running Linux in a VM settled on a Synology DS and inside you are running one or more Docker containers?
This setup is way to complicated for me and maybe wastes too much RAM and CPU cycles, isn't it?

I wouldn't say it's a waste of RAM en CPU cycles. As stated in the post I shared earlier, MailCow cannot run straight on a Synology NAS due to it's customizations and limitations Synology did on it's Docker engine (as @one-eyed-king pointed out multiple times on this forum).

So even tough it's an increase of CPU and RAM, my DS718+ with 16 GB of RAM is handling it just fine considering all the other stuff I have running on this NAS:

In a sense, this could be turned into a positive trade-off. For example in this post @one-eyed-king gave me massive help setting up a separate NGINX instance in a Docker container. So I could use that as a reverse proxy server instead of the Synology DSM RP. This gave me the ability to no longer expose the Synology DSM directly to the internet, so port forward 80 & 443 to the nginx docker container instead. However, it would maybe be even more secure if I would move this NGINX docker container onto this Linux VM I'm running. So if any hacker manages to find some way to get past my security and gain entry, it would end up not only in just a container but also on an OS with nothing on it.

Every advantage can have a disadvantage.
But every disadvantage can potentially be turned in an advantage... LoL..

 

[Shoop]

"setting up a separate NGINX instance in a Docker container. So I could use that as a reverse proxy server instead of the Synology DSM RP. This gave me the ability to no longer expose the Synology DSM directly to the internet, so port forward 80 & 443 to the nginx docker container instead"

Hmmm ... Curious on what exactly you achieved ? I wanted to move the DSM login page from "https://my.ddns/" to "https://my.ddns/<anypathlessobvious>" and still did not find any clue how to do it.
I currently have setup the RP for other synology apps like Notes, Files, Moments but can't find a way to hide DSM which remains visible "https://my.ddns/".
If you found something (not too much complicated) to do it I'm interested :P

 

[Rusty]

I wanted to move the DSM login page from "https://my.ddns/" to "https://my.ddns/<anypathlessobvious>" and still did not find any clue how to do it.

You can do this with reverse proxy if you have your own domain name. Just add your custom domain and redirect to your local nas IP address and dsm port. No way to do this for the main DSM login as oppose to other syno apps.

 

[Shoop]

You can do this with reverse proxy if you have your own domain name. Just add your custom domain and redirect to your local nas IP address and dsm port. No way to do this for the main DSM login as oppose to other syno apps.

Already done for other syno apps (https://my.ddns/<app>) with the built-in RP but what I wanted to do is move it also for main DSM login but couldn't find a way even with an nginx custom config file and as I saw @Shadow seems to have been able to move this one also :

This gave me the ability to no longer expose the Synology DSM directly to the internet

Or maybe I misunderstood what he meant ...

 

[Shadow]

Or maybe I misunderstood what he meant ...

Well I don't use quickconnect or Synology DDNS as URLs to get to my NAS (internal or external network). I purchased my own domain. To get to my normal DSM login page, I have to use a specifiek URL or for my reverse proxy to propaly route the request.

nginx.conf:

...
server
    {
        # set DNS resolver as Docker internal DNS
        resolver 192.168.1.194 valid=10s;
        resolver_timeout 5s;
        # Pass header info to the target service
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;
       
        proxy_buffering off;
        # Connection upgrade to HTTP1.1
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        server_name nas3.***.net;
        # NGINX listener (at the container level)
        listen 443 ssl;
        listen 5001 ssl;
        #listen 80;
        # Supported HTTPS protocols
        ssl_protocols TLSv1.2;
        # SSL Certificate components (bound mind from host)
        ssl_certificate /certs/carddav/fullchain.pem;
        ssl_certificate_key /certs/carddav/privkey.pem;
        location /
        {
            set $target http://dockerhost1.***.net:5000;
            proxy_pass $target;
        }
    }
...

BTW: Aren't we off-topic..?