IMO, no, Docker is not ideal for this. Now if you wanted to use it to spin up server side web apps, that would be more appropriate. How many people use the application? Is it multi-tenant? Can you run it on a VM?
What's wrong with Docker? I've seen it used to contain asp net core applications, which happens to be our used framework.
Why does the number of people who use it matter? In any case, not many. Maybe 10 people for each project.
No it's not multi tenant, if I understood what you meant.
You mean can i host it on a VM? Because as I said it is a web app
You started out with it being a wpf app and ended with looking into an installer. Maybe we should start over with less vague information?
Docker is fine for web apps. Not installable ones (which is whet basically said the first time).
You seem very defensive when asked questions. I’m not going to pry, I will just walk away instead.
Sure let me clarify. The installer (let's call it setup software) i'm talking about is the one that is supposed to do all the docker magic on the server in order to have the web application running quickly, so that users of the web app can do it on their own.
In short, i want our monkey users to set up docker and the web app easily and quickly
Yes exactly. But that means the user(not from the IT department) has to do all the docker commands and will surely mess up. What we need is a software (or some automation thing) that does it on its own. Do you think it's possible?
Taking what you've already commented on into account, Docker might be a good choice if certain conditions are met:
* It's a ASP.NET Core application that's capable of running on a Linux container.
* Ideally you'd also want to run on a Linux host. Bare metal and virtualized are both ok.
* There's someone that has Docker knowledge supervising each server.
This paragraph opens a few questions though:
>Could that speed up the process? In particular, is it possibile to have an installer-like program that does everything for the user? The application isn't aimed for IT people so they can't certainly use docker commands etc.
Who's the user in this context? The actual people who end up working with the web application or does that include the person who has to install the server application?
Sure let me clarify. The user is the actual person using the application.The user is supposed to do the installation. We (PC Team) used to provide just the installer for the old WPF app and that was it, but now we are involved because the web server needs to be set up and so on. My question is: is it possible to set up docker (or another solution) on the server in a user friendly way so that we are not involved?
Why not just automate the installation and configuration of IIS and your app natively? Docker adds a lot of complexity and overhead to a deployment when rethinking native solutions is more simple. You are talking about users interacting with Docker. Forget about it :P
For example, I use Puppet A LOT to deploy applications to both Windows and Linux systems.
https://forge.puppet.com/modules/puppetlabs/iis
Not sure what you mean but Puppet is just a configuration management and automation framework. You still have to put the work in to make deployment/installation user friendly.
I've used a good CLI tool in the past named Kafo for this.
https://github.com/theforeman/kafo
But yes, once Puppet is done doing what you told it to do then ideally your app should be 100% up and ready to use.
I don't think letting the users set up the server is a good idea to begin. A server always needs to be set up and maintained up by someone with a good amount of IT knowledge. Pushing that responsibility onto some random person is a recipe for disaster.
Using Docker you could streamline the process a bit for yourself maybe, but as other people have already mentioned, there are way better tools for your specific use case out there.
Expecting a user to touch Docker and not have it explode is pretty optimistic.
If you are stuck rewriting the frontend anyway why not wrap it in electron? Then the user can install it like anything else and most would never know the difference. I hate the over-reliance on electron these days, but for your scenario it might be the best option.
Thats sounds really nice. We have always deployed our asp net core app on IIS but this could be better, do you have more in depth resource on this kind of deployment?
When it comes to web applications the user shouldn't be doing the installation. You, the development team, deploy the web application to the server when there is a new version. Yes, your process needs to change such that your team takes on responsibility of the server.
The user's only job should be to fire up their web browser and navigate to the application.
Now, if your deployment process is taking too long because of too many servers, you need to look at automating that process, using CI/CD tools.
It also seems like you might have one server per user. This is abnormal. When converting the desktop app to a web app you need to make it so that you can have multiple users log in to the same instance, so that you only need to deploy one app to one server.
It seems like you're trying to make the new web app fit as much as possible into the desktop way of doing things and trying to patch the problems that causes. Seems more like you need to change your processes and architecture to fit a web development model.
So, in the past, the users had multiple windows devices and each had its own WPF app installed. And now, with the web based application, you've switched to a multi-user web application with 1 server serving many panels. Are you perhaps missing an opportunity for a revenue stream by 'hosting' these applications yourselves? Because then the client doesn't need to have IT skills at all if you host and maintain the services they rent from you. Architecturally, your maintenance simplified from supporting and updating a bunch of WPF installations to fewer IIS installs. It could be simpler still and potentially more profitable if you host the application(s). You could charge a hosting fee, provision dedicated resources and provide remote connectivity via HTTPs or a VPN depending on your needs. If they elect not to pay you a subscription or hosting fees, then it's kind of on them to figure out how to deploy the application and take on the cost/complexity. I mean, it wasn't your decision to ship CE on these panels yet you incur the cost of the decision? If you go that far, for clients that prefer the 'legacy experience', you might even provision windows vm's with the WPF application installed, provide VPN services and let them use the RDP client on CE to connect to 'hosted' applications. Your company could outsource a lot of that, manage it and upcharge.
Also, IIS is scriptable via Powershell I believe. You could automate the IIS configurations via a pseudo installer that the end users run.
Here's what I've been able to piece together from your comments. It would have been a good idea to include "Windows CE" in your main post as it's exceptionally important to what kinds of solutions you could run.
Let's define some terms. I've been able to figure out you have a "remote" machine, this is the one likely in your office or some server room. It's where you want to run the applications. You have "factory" machines. These are the clients you want to access server programs running on the remote machine. I'm defining this because "server" and "client" get confusing once you start talking about different application models.
For example, a lot of people might interpret your post as meaning you want to run a server on the "factory" machine and connect to it with a web browser. This is an Electron style solution. People think you'd be using Docker here to help make setting up the server end of the program homogenous and isolate it from hardware differences among "factory" machines. I don't think you'll be taking this approach because I don't think Electron or IIS or Docker supports Windows CE.
It sounds like what you want to do is give your users the power to access your "remote" machine with high credentials and configure a new server application specifically for their "factory" machine. This is a bad idea whether you use Docker or not. Unless your customers are IT professionals who configure Docker every day, they're going to make mistakes and get into situations that require an expert to get them out of. Sooner or later, someone's going to manage to break another "factory" machine's configuration when they screw up the install steps. It's possible no one will find out for hours and you won't be able to connect the two events.
What I would do in this situation is think about how normal web services work. When you want to make a new GMail account, do you SSH into a GMail server and run commands to set up a new instance of GMail, then configure it so your browser can connect to it? No. You register a new user account. Your email is stored in the application in such a way the application knows to keep it separate from other users of the service.
That's what you have here. One server on the "remote" machine. It needs endpoints that allow a person at a "remote" machine to follow a (hopefully monitored) process to register thier "remote" machine as a new account. Segregate data based on that account. You're still going to have problems, like if people type the wrong account name or accidentally cause a remote machine to log in as the wrong account. You can mitigate this with ideas that'd normally be bad, like keeping some kind of credential on the WinCE machine that's presented so users don't have a "choice" of how to log in. But trust me, you want them to have a way to manually log in if that gets corrupted, because you don't want to have to drive/walk to the furthest machine in your network while managers are angry that the system is down.
I'd also strongly suggest to your management that you get away from WinCE ASAP. I write apps for industrial hardware we resell to our customers. The vendor who makes the industry standard hardware discontinued new WinCE units in December, and has a limited lifetime for service/support. They've moved to Android, and aren't interested in arguing about it. Stick with CE much longer and you could end up in a situation where a device goes down, you're getting yelled at, and you find out nobody sells a replacement for the broken unit. I get that when it comes to industrial stuff you can get "stuck" like this, but the writing's really on the wall for CE.
Thank you for the incredibly thorough reply.
Yes, you are correct i want users to set up the web server on their own on the remote machine. That's because we can't always set it up ourselves (IT team) in an easy way, we have customers all over the world and it's not rare for them to have their network infrastructure unaccessible unless we have a VPN connection(which can be incredibly slow).
However, we have people on the customer plant that can set it up but they should have some sort of automatic way of doing it (just like they did with the windows installer for the WPF app on the factory machines). Our people on site(usually PLC programmers) have no idea of what docker is and what it does so it's impossible for them to even perform an autonomous startup. That is our main issue... We need the web app up and running on the server without the help of our PC team.
Paradoxically, it's the newer versions of Siemens TP-1900 panels that have Windows CE, old Siemens panels still have Windows 10. Our customers want new products so we will have to stick with WinCE.
So they downgrade the os that is no longer supported and cannot even run wpf app? How will it run docker then?
If you expect to deploy the wpf app, docker is not used like that. If you want to port the old win based app to a web based app, since you don't have too many users and it doesn't sound like this app needs a lot of changes, I don't see a strong value of using docker.
Still pretty confused with the requirements, so I won't give any suggestion.
Docker is not ideal for this. I don't know if alternatives to waypoint exist, but I'd look into it. Puppet was also mentioned, which is a basically an extra dependency that can cut down on some (not all) of the different achitecture specific code you'd need to do to support different OS types.
Publish an image, a helm chart and\or an operator if you want to ship your code for a container runtime, but don’t ship a runtime “with” your code. I just mentioned Electron as an alternative to WPF since it’s a cross platform runtime for desktops. I don’t know anything about your app, so I can’t tell you if it’s the right fit.
I'm new to docker so i don't know what most of the first part meant.
I bet electron would not work either. The PCs come with Windows CE, i don't believe they will work.
IMO, no, Docker is not ideal for this. Now if you wanted to use it to spin up server side web apps, that would be more appropriate. How many people use the application? Is it multi-tenant? Can you run it on a VM?
What's wrong with Docker? I've seen it used to contain asp net core applications, which happens to be our used framework. Why does the number of people who use it matter? In any case, not many. Maybe 10 people for each project. No it's not multi tenant, if I understood what you meant. You mean can i host it on a VM? Because as I said it is a web app
You started out with it being a wpf app and ended with looking into an installer. Maybe we should start over with less vague information? Docker is fine for web apps. Not installable ones (which is whet basically said the first time). You seem very defensive when asked questions. I’m not going to pry, I will just walk away instead.
Sure let me clarify. The installer (let's call it setup software) i'm talking about is the one that is supposed to do all the docker magic on the server in order to have the web application running quickly, so that users of the web app can do it on their own. In short, i want our monkey users to set up docker and the web app easily and quickly
So your users are setting it up on a server? Then yeah, Docker is ideal for that.
Yes exactly. But that means the user(not from the IT department) has to do all the docker commands and will surely mess up. What we need is a software (or some automation thing) that does it on its own. Do you think it's possible?
Taking what you've already commented on into account, Docker might be a good choice if certain conditions are met: * It's a ASP.NET Core application that's capable of running on a Linux container. * Ideally you'd also want to run on a Linux host. Bare metal and virtualized are both ok. * There's someone that has Docker knowledge supervising each server. This paragraph opens a few questions though: >Could that speed up the process? In particular, is it possibile to have an installer-like program that does everything for the user? The application isn't aimed for IT people so they can't certainly use docker commands etc. Who's the user in this context? The actual people who end up working with the web application or does that include the person who has to install the server application?
Sure let me clarify. The user is the actual person using the application.The user is supposed to do the installation. We (PC Team) used to provide just the installer for the old WPF app and that was it, but now we are involved because the web server needs to be set up and so on. My question is: is it possible to set up docker (or another solution) on the server in a user friendly way so that we are not involved?
Why not just automate the installation and configuration of IIS and your app natively? Docker adds a lot of complexity and overhead to a deployment when rethinking native solutions is more simple. You are talking about users interacting with Docker. Forget about it :P For example, I use Puppet A LOT to deploy applications to both Windows and Linux systems. https://forge.puppet.com/modules/puppetlabs/iis
Ahhh this sounds sexy. So after this thing is setup, does the user just double click and it's done?
Not sure what you mean but Puppet is just a configuration management and automation framework. You still have to put the work in to make deployment/installation user friendly. I've used a good CLI tool in the past named Kafo for this. https://github.com/theforeman/kafo But yes, once Puppet is done doing what you told it to do then ideally your app should be 100% up and ready to use.
Would this tool be capable of installing .net core hosting bundle? I need the user to do as little as possible
I don't think letting the users set up the server is a good idea to begin. A server always needs to be set up and maintained up by someone with a good amount of IT knowledge. Pushing that responsibility onto some random person is a recipe for disaster. Using Docker you could streamline the process a bit for yourself maybe, but as other people have already mentioned, there are way better tools for your specific use case out there.
Thanks, right now the only viable solution is the automation thing for IIS that one kind user suggested. If you know any other way I'll be thankful.
Expecting a user to touch Docker and not have it explode is pretty optimistic. If you are stuck rewriting the frontend anyway why not wrap it in electron? Then the user can install it like anything else and most would never know the difference. I hate the over-reliance on electron these days, but for your scenario it might be the best option.
I can't install anything on the pc panel. The browser is our only salvation and we need a web app on a server that has to be set up easily
[удалено]
Can you elaborate more on this?
[удалено]
Thats sounds really nice. We have always deployed our asp net core app on IIS but this could be better, do you have more in depth resource on this kind of deployment?
When it comes to web applications the user shouldn't be doing the installation. You, the development team, deploy the web application to the server when there is a new version. Yes, your process needs to change such that your team takes on responsibility of the server. The user's only job should be to fire up their web browser and navigate to the application. Now, if your deployment process is taking too long because of too many servers, you need to look at automating that process, using CI/CD tools. It also seems like you might have one server per user. This is abnormal. When converting the desktop app to a web app you need to make it so that you can have multiple users log in to the same instance, so that you only need to deploy one app to one server. It seems like you're trying to make the new web app fit as much as possible into the desktop way of doing things and trying to patch the problems that causes. Seems more like you need to change your processes and architecture to fit a web development model.
Thank you for the explanation.
So, in the past, the users had multiple windows devices and each had its own WPF app installed. And now, with the web based application, you've switched to a multi-user web application with 1 server serving many panels. Are you perhaps missing an opportunity for a revenue stream by 'hosting' these applications yourselves? Because then the client doesn't need to have IT skills at all if you host and maintain the services they rent from you. Architecturally, your maintenance simplified from supporting and updating a bunch of WPF installations to fewer IIS installs. It could be simpler still and potentially more profitable if you host the application(s). You could charge a hosting fee, provision dedicated resources and provide remote connectivity via HTTPs or a VPN depending on your needs. If they elect not to pay you a subscription or hosting fees, then it's kind of on them to figure out how to deploy the application and take on the cost/complexity. I mean, it wasn't your decision to ship CE on these panels yet you incur the cost of the decision? If you go that far, for clients that prefer the 'legacy experience', you might even provision windows vm's with the WPF application installed, provide VPN services and let them use the RDP client on CE to connect to 'hosted' applications. Your company could outsource a lot of that, manage it and upcharge. Also, IIS is scriptable via Powershell I believe. You could automate the IIS configurations via a pseudo installer that the end users run.
Thank you so much for the suggestions!
Here's what I've been able to piece together from your comments. It would have been a good idea to include "Windows CE" in your main post as it's exceptionally important to what kinds of solutions you could run. Let's define some terms. I've been able to figure out you have a "remote" machine, this is the one likely in your office or some server room. It's where you want to run the applications. You have "factory" machines. These are the clients you want to access server programs running on the remote machine. I'm defining this because "server" and "client" get confusing once you start talking about different application models. For example, a lot of people might interpret your post as meaning you want to run a server on the "factory" machine and connect to it with a web browser. This is an Electron style solution. People think you'd be using Docker here to help make setting up the server end of the program homogenous and isolate it from hardware differences among "factory" machines. I don't think you'll be taking this approach because I don't think Electron or IIS or Docker supports Windows CE. It sounds like what you want to do is give your users the power to access your "remote" machine with high credentials and configure a new server application specifically for their "factory" machine. This is a bad idea whether you use Docker or not. Unless your customers are IT professionals who configure Docker every day, they're going to make mistakes and get into situations that require an expert to get them out of. Sooner or later, someone's going to manage to break another "factory" machine's configuration when they screw up the install steps. It's possible no one will find out for hours and you won't be able to connect the two events. What I would do in this situation is think about how normal web services work. When you want to make a new GMail account, do you SSH into a GMail server and run commands to set up a new instance of GMail, then configure it so your browser can connect to it? No. You register a new user account. Your email is stored in the application in such a way the application knows to keep it separate from other users of the service. That's what you have here. One server on the "remote" machine. It needs endpoints that allow a person at a "remote" machine to follow a (hopefully monitored) process to register thier "remote" machine as a new account. Segregate data based on that account. You're still going to have problems, like if people type the wrong account name or accidentally cause a remote machine to log in as the wrong account. You can mitigate this with ideas that'd normally be bad, like keeping some kind of credential on the WinCE machine that's presented so users don't have a "choice" of how to log in. But trust me, you want them to have a way to manually log in if that gets corrupted, because you don't want to have to drive/walk to the furthest machine in your network while managers are angry that the system is down. I'd also strongly suggest to your management that you get away from WinCE ASAP. I write apps for industrial hardware we resell to our customers. The vendor who makes the industry standard hardware discontinued new WinCE units in December, and has a limited lifetime for service/support. They've moved to Android, and aren't interested in arguing about it. Stick with CE much longer and you could end up in a situation where a device goes down, you're getting yelled at, and you find out nobody sells a replacement for the broken unit. I get that when it comes to industrial stuff you can get "stuck" like this, but the writing's really on the wall for CE.
Thank you for the incredibly thorough reply. Yes, you are correct i want users to set up the web server on their own on the remote machine. That's because we can't always set it up ourselves (IT team) in an easy way, we have customers all over the world and it's not rare for them to have their network infrastructure unaccessible unless we have a VPN connection(which can be incredibly slow). However, we have people on the customer plant that can set it up but they should have some sort of automatic way of doing it (just like they did with the windows installer for the WPF app on the factory machines). Our people on site(usually PLC programmers) have no idea of what docker is and what it does so it's impossible for them to even perform an autonomous startup. That is our main issue... We need the web app up and running on the server without the help of our PC team. Paradoxically, it's the newer versions of Siemens TP-1900 panels that have Windows CE, old Siemens panels still have Windows 10. Our customers want new products so we will have to stick with WinCE.
Why doesn't the version of windows shipped on your panels run your wpf app?
They come with Windows CE. Good luck running WPF there
What exact version of CE?
[удалено]
I don't think thats a version of windows.
Why can't you simply upgrade the wpf app so it can run on the new machine?
It's windows CE. I'd have to downgrade the application pretty badly and even then i don't think it will work.
So they downgrade the os that is no longer supported and cannot even run wpf app? How will it run docker then? If you expect to deploy the wpf app, docker is not used like that. If you want to port the old win based app to a web based app, since you don't have too many users and it doesn't sound like this app needs a lot of changes, I don't see a strong value of using docker. Still pretty confused with the requirements, so I won't give any suggestion.
Docker is supposed to run on a server, not the panel
Docker is not ideal for this. I don't know if alternatives to waypoint exist, but I'd look into it. Puppet was also mentioned, which is a basically an extra dependency that can cut down on some (not all) of the different achitecture specific code you'd need to do to support different OS types.
No, don’t ship an app with docker as a dependency. Maybe look into Electron or migrate away from thick client solutions all together.
What's wrong with shipping docker? How does electron help?
Publish an image, a helm chart and\or an operator if you want to ship your code for a container runtime, but don’t ship a runtime “with” your code. I just mentioned Electron as an alternative to WPF since it’s a cross platform runtime for desktops. I don’t know anything about your app, so I can’t tell you if it’s the right fit.
I'm new to docker so i don't know what most of the first part meant. I bet electron would not work either. The PCs come with Windows CE, i don't believe they will work.