I have a hub and spoke wireguard nerwork that has been working somewhat perfectly for years, but there always are a couple of servers that just dont want to play nice. They connect to the hub, all good, and after a few minutes/hrs connection drops and handshakes fail. Using wireguard-go on docker (older linux machines) for all of them. Its a pain.
We develop one or more apps that we deploy on-prem. An app for us is a git repo with a docker compose file. On-prem is either a Linux server or a Linux vm that we have ssh access to (normally via Wireguard vpn).
For app updates, we use ansible to ssh into machines, run pre-deployment scripts, pull git repo and docker images, restart containers and run post-deployment scripts.
It could be better, but it works for us.
The biggest bottleneck we have now is communication with customers, scheduling of updates, letting them know of breaking changes or new features, that kind of stuff.
The apps are provided "fully managed". They dont know and don't care about the details I just described, but they do need assurances that everything is done "properly".
What we think would help us a lot is a way to easily let them know of new releases of any apps they have installed, let them read release notes, docs, and be able to either deploy on-demand or schedule a deployment at a certain time.
Although having fewer things for us to do is nice, what is crucial is to oversee deployments and make sure they are successful (and intervene if not).
We already have a customer portal where you can display any information you want for your customers. We also provide container and deployment logs, as well as alerts in the platform, so you can immediately see if an update failed and what went wrong. Release notes are already on our roadmap, and a lightweight issue tracker has also been requested.
Scheduled updates are currently not on the roadmap, but we’d be happy to scope that feature together and add it.
Thats a great idea, and was my original plan. However, it just didn't make sense given the time and level of the response. The audit report is pretty straightforward, and has all of the details. I assume the technical folks who want to go deeper will read the full report.
The response to the feedback and to give some background was what was needed on our side, and we wanted that to be accessible to non-devs as well.
More like giving formula for free to new mothers to begin with, and when they wouldn't produce their own (as there was no "demand") they would later need to buy more formula.
There was a stackoverflow question (IIRC) long ago on how to disable a mobile phone's camera shutter sound, and the answer was to record the sound, inverse it and play it when the camera is activated so that the two sounds cancel each other out. Not sure if it worked though, or if it helps in your case, as precise timing is needed for this to work.
reply