Why is this necessary - because I am just a contractor who is remote and very part time for a startup without it’s own tech resources.
What is the goal - A completely pre-configured, commissioned, and ready to go Edge Gateway for their local HMI systems.
I have been battling for the last 3 weeks solid to get even remotely close to this goal and it, quite frankly, seems like the developers never even considered this to be necessary. So, what is the catch 22? You cannot fully configure the gateway without using the rest API, you cannot use the Rest API without an API key, you cannot configure the API key using the JSON files. That means you cannot fully setup and configure certain things like MQTT.
Thus, I am left in an impossible situation. I can have a partially configured useless lump sitting there and I get to burn PTO from my 9-5 in order to go and setup an ignition edge site randomly.
The documentation on the JSON files and their schemas is sparse at best. The docker image is similarly sparse and really not useful.
I have searched every corner of the web I can think of to see if anyone has had more success than I and I cannot find a soul who has come close. Even Mustry-Solutions/ignition-83-cicd didn’t get me much further down the road.
Everything says well use a gateway back up - that completely defeats the entire purpose, that would just be me manually setting up everything in the UI every time and then just packaging it for docker because not every system project is identical, but the basics will all be the same.
So, has any one actually accomplished a fully pre-configured deployment, docker or otherwise?
I haven’t migrated my 8.1 automated deployment yet, but I’m not anticipating any showstoppers.
I reckon I’ll add myself to the list, and echo to start with a gateway backup. Configure a single gateway in the UI, then use that gwbk for all future gateways. The gwbk can be restored via script (immediately following your automated install), and would contain the base config for your client - things common to every gateway. With any luck, that could include MQTT configuration…
Personally, I’m not a believer in Docker for bare metal Edge installs. To each their own…
Regarding the API key:
Regarding any other specific hurdles you encounter, inquire here.
Using a gateway backup is the worst copout there is, here is why that is a flawed way to do that:
Every single edge now has the exact same API key - bad for security at the very least
It will include the wrong project, tags, and alarm pipelines unless I do a barebones gateway and back it up.
Even if I do barebones there isn't even a sure-fire way to ensure it will fully deploy and be able to configure everything.
The post you link at the bottom says "....The solution posted here assumes you have already created an API Key with Write permissions and are using that API Key to automate creation of further API Keys."
that means I would have to have created an API key in the UI first unless I am not reading it correctly, so that solution doesn't work if that is true. I am resigned to the fact I am likely to have no other choice, but part of the entire supposed advantage was these JSON config files. That falls flat so far.
As for why docker - it gives me a standard, portable, and reproduceable item. It will deploy on windows or linux. I can much more easily package all of the necessary items in the image (assuming I can ever get it actually work).
Preconfigure an API key as a file resource as shown in the link.
On deployment, use that API key to generate another specifically for that new system, and use it with the API to delete the preconfigured key. Et Voila, unique system API key for you.
Yes, one time, on some gateway somewhere, you will have to use either the UI or a pre-existing API key to generate the primordial API key bootstrap files you’ll start copying around. This is your temporary “admin/password” key you seed new gateways with before you then generate a new one and delete the temporary one.
The problem I had and may still have (I am currently working on it), is that the API key isn't/wasn't generating. The error was unclear. I might have figured it out though but we shall see - and if I get a solid deployment script for all of it - I will make it more generic and able to take some inputs and post it here. Inputs wouldn't be a fully complete automated deployment but the people that need that can likely figure out how to solve the inputs problem.
I am really looking forward to being able to have a dedicated local drive for the local store and forward. That is a really awesome part of this.
Optionally, using a bare-bones gwbk as a starting point for your deployments…
To elaborate on my previous post - I’m not suggesting that the restoring of a gwbk is going to be a ‘ready-to-deploy’ solution. I’m merely suggesting that you use it as a convenient tool to preconfigure a bulk of items which are client-specific & common to all Edge gateways. This gwbk can include LDAPS (user source & IDP) configuration, complete with the SSL cert to work with that configuration. If every Edge gateway connects to a single central / full Ignition gateway, then you can configure that outbound connection, Edge Sync configuration, & include the remote gateway certificate in the gwbk. Your use-case will vary. For everything else (site specific), use the API, EAM, etc.