Portainer/Portatiner is now deprecated

[Airfoil73]

Portainer/Portatiner is now deprecated. Can you update it so it is using portainer/portainer-ce. https://hub.docker.com/r/portainer/portainer-ce

[Paraphraser]

@Slyke I volunteer to submit a PR for this.

[Paraphraser]

@Slyke I'll start by declaring that Portainer is something I could easily live without. To be perfectly honest, I struggle to see the point of it. If I were to proceed strictly from my own limited perspective, I'd be totally gung-ho. I've implemented -ce on my RPis and it seems to work out-of-the-box so I'd have no trouble creating a PR to change the template. It's the classic one-line-change.

But...

The Portainer release doco has got more bold-faced notes and warnings than a kid with chickenpox. Just because I don't get the point of Portainer doesn't mean there aren't others who depend on it and whose IOTstack installations may break if -ce is foisted on them and it exposes a dependency on one of the said notes and warnings.

I realise that such a user would have to "pull full service from template" to fall into a hole but, on balance, I think a little more caution might be warranted.

Several possible approaches spring to mind:

1. Do nothing until a -ce release with fewer warnings. The basic problem with this approach is that the "extensions" issue is never going to go away:

   Extensions have now been removed; there is now no ability to use RBAC, Registry Manager, or External Authentication extensions in CE 2.0 (Extension customers will be communicated directly with a free license for the upcoming Portainer Business Edition). EXTENSION USERS, DO NOT UPGRADE TO PORTAINER CE 2.0

2. Change the template service.yml so that the user can pick & choose for the price of a trip through a text editor:

     portainer:
       container_name: portainer
       # enable ONE of the following
       image: portainer/portainer
       #image: portainer/portainer-ce
       restart: unless-stopped
       ports:
         - "9000:9000"
       volumes:
         - /var/run/docker.sock:/var/run/docker.sock
         - ./volumes/portainer/data:/data
   

   This actually works quite well, to the point of being able to switch back and forth in the space of a few seconds (once both images have been pulled). The two versions don't seem to care about sharing the same structures in volumes but that might have more to do with my unsophisticated use of the app. Someone with lots of add-ons may find things broken by a round-trip.

3. Duplicate "portainer" as "portainer-ce", with docker-compose.yml potentially looking something like:

     portainer:
       container_name: portainer
       image: portainer/portainer
       restart: unless-stopped
       ports:
         - "9000:9000"
       volumes:
         - /var/run/docker.sock:/var/run/docker.sock
         - ./volumes/portainer/data:/data
   
     portainer-ce:
       container_name: portainer-ce
       image: portainer/portainer-ce
       restart: unless-stopped
       ports:
         - "9002:9000"
       volumes:
         - /var/run/docker.sock:/var/run/docker.sock
         - ./volumes/portainer-ce/data:/data
   

   This also seems to work quite well, although I did get an "Unable to retrieve endpoints" error at one point, plus Safari stopped being able to repaint the 1.24.1 screen correctly. I could not replicate either in Chrome and both problems went away after I voided Safari's cache. I'm assuming Safari got confused by the way I kept moving the ground beneath its feet.

Options 2 & 3 give each user the choice. Option 2 keeps a single port and single data store at the price of a docker-compose.yml edit and an "up". Option 3 forces the user to deal with a second port (at least during the migration period) but does allow side-by-side comparison of old vs new for any sophisticated users.

On balance, I'm leaning towards #3. Thoughts?

[Slyke]

Hmmm... I'd like to go with option 1, but worried about the warnings that come up. We'll give them a few releases and see how they are going.

Option 2 might work, but there might be breaking breaking changes (or non-backwards compatible changes) to Portainer-CE, and switching back to Portainer 1.24.x might cause it to fail and possibly destroy saved data (worst case scenario).

For now, I think the best choice is to do option 3. I will code both of them in. On the new menu I will add in a warning on the menu when selecting the deprecated Portainer that it is deprecated and could be removed from IOTstack at any time.

[jmorris644]

I vote for option 3. I installed -ce on a test system and so far no issues. Having to use a different port is a very minor nuisance

[877dev]

Number 3 here as well.

I use Portainer all the time, it would be nice to have CE version so I can check it out without fully committing.

[AntumArk]

I vote for 3,. Having two stable versions is needed so people could slowly migrate from one to another. Then the old version can be deprecated fully.

[Paraphraser]

In testing, I noted the presence of port 8000 for Portainer-ce, which is described as:

Port 8000 is a SSH tunnel server and is used to create a secure tunnel between the agent and the Portainer instance.

The updated definition will need to be:

  portainer-ce:
    container_name: portainer-ce
    image: portainer/portainer-ce
    restart: unless-stopped
    ports:
      - "8000:8000"
      - "9002:9000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./volumes/portainer-ce/data:/data

[Slyke]

Okay, I added deprecation warning on the new menu (experimental branch) when selecting portainer, and also added the portainer-ce service directly below it. Do note that it is untested right now.

[Paraphraser]

For anyone running on the master branch, Portainer CE is now listed in the menu. You will find instructions here

[jmorris644]

For anyone running on the master branch, Portainer CE is now listed in the menu. You will find instructions here

When I ran menu.sh it stated that it updated but Portainer-ce is not in the Build list.

[Paraphraser]

Possibly just try again. It might be a chicken and egg. Running the menu does a git pull but the menu probably isn't smart enough to realise it has changed and restart itself. To be absolutely sure you could do a git status and make sure it says "on branch master" (if not, git checkout master) then a git pull.

If it still doesn't work, please check ~IOTstack/.templates. If you see portainer-ce then it indicates the template came down to your machine, so any problem will likely be in the menu.sh. If the git status suggests menu.sh has changed then the reason might need to be resolved first.

I have an RPI3B+ which I keep as a pristine straight clone from IOTstack. I tested on that and it just worked but, thinking back, I probably did a git pull, then checked .templates, then did a grep "Portainer-ce" menu.sh, all to satisfy myself that everything had come down - then I ran the menu and selected it.

[jmorris644]

hmmm....

Git status reports origin/master
so I did a git checkout master and it stated I was already on master and that master was up to date.

I checked the .templates and no Portainer-ce present.