I did not understand who uses only default containers without configuration or only the small possible container configurations? For such people a default UI is perfect.
E.g. Containers with Linked Data-Containers to store the Data outside of a container, or setting up a container with different parameters (company/server specific). For such things i need an extra system which can not be used with your or any other UI.
We build our own small template system to manage Domains, Subdomains and the setup of the software within a container. How could this be connected to your UI?
It would be great if your Template-System will integrate an API, so really configurable Templates will be possible. Allow external Scripts, or better access to an Rest-Api to get configurations. This will be a huge advantage over other standard UIs.
What ways are you injecting new data in? This service appears to support environment variables (which sounds right for setting up a container with different parameters) and volumes, do those not meet your needs? I'm always slightly hazy on the volumes-from data-container pattern so perhaps not.
I mean how dynamic data come into the Container from the UI, when you setup a new container? I use the data to setup the container, get letsencrypt certificates, update nginx proxy, add to backups, ....
Example: I setup a new Apache+PHP-Container with Domain xyz.com, now i want to add a subdomain abc.xyz.com. How can i do that with the UI and automatically inform my other components about the changes. That is what i mean with, that the UI solve not this problem for me and it has no API to connect. Or their template system is not flexible enough to handle such things.
Currently my data is stored in conf files and i use some custom scripts to create / update the docker containers, update proxy, ....
The main advantage against shipyard is that you only need to deploy one container to run Portainer, it's really simple and quick. Shipyard deployment is more complex.
I wouldn't be too surprised if your test cluster machines are frequently rooted.
It should be noted that this project still lacks proper access management. There is no authentication either. You can set up Basic Auth but it feels dirty in my opinion. Guard it behind your firewall if you are gonna use it in production.
Kudos
Really looking forward to the docker-compose support, though. I like the combination of docker-compose + traefik + labels. :)
Say I don't wanna ship logs elsewhere, can I define a retention period and check out logs locally?
ty
There's not so much content in it at the moment, but we plan to work on it this week :)
As a result they aren't terribly good at anything (The UI is insanely slow). Other specialized tools that just focus on one orchestration framework could zoom past Rancher. Look at the Kubernetes UI in 1.4.
1. Is there some auth mechanism like Shipyard where I can make new users and set their access scopes?
2. Can you please mention the source code on your page? It is nowhere to be seen (https://github.com/portainer/portainer).
Role based access control is our next big feature on the roadmap, we're working on it :)
And yes, there is a link to the source code on the homepage.
Glad to see that you say services are being worked on. I see that as a good area to push forward on in Docker land.
Both projects just named themselves based on an extension of the shipping-container analogy - "things that help manage lots of containers".
