I like the design of Statusfy and some of its features, but as written, other solutions with an admin interface/db are much easier and faster to use. But this has the downside of long build/publish times and the need of setting up a deployment chain and you need dev knowlege/access rights in a dev env.īoth have lots of cons, i.e. Every State change (that is a commit) leads to a rebuild of the container and redeployment. And working on this external data-store is also not ideal, as you need access to the system.Ģ.) Statusfuy is more suited to the model, keeping state in a git repo and "build it into" the Container itself. However Stausfy ist not ideally suited for this setup, as changing data needs to run a command in the container to rebuild the site, which is hard to trigger externally. Thanks! And thanks for statusfy, really love it!įor all those interested, I learned a lot the last weeks regarding this, here are the two options you have:ġ.) As described above by me, you can put Statusfy in an empemeral Docker Container and "extract"/keep state external (host moúnted dir/persitent volume). What security implications and leakages does this have? Can someone please comment on this if this is the way to go and also include a short paragraph about best practices in the documentation about containerized usage. Some of the features offered by StatusDashboard are: Fault Tolerant. StatusDashboard and Statusfy can be primarily classified as 'Status Page Hosting' tools.
You can easily create a fast Static Generated System and easily deploy it to a variety of hosting services. I am a newbie with nuxt/vue: One solution for automatic reloading seems to run the app with "npx statusfy dev" in the container. Statusfy is a Status Page System, easy to use and completely Open Source. Currently there is no "reloading" command (that could be triggered via a cronjob or that does the reloading itself). But this very hard to implement properly and leads to downtimes. This would however then require "npx statusfy build & npx statusfuy start", in other words a reloading in the contianer. So I would not be using the "new-incident" command (as this command is not available outside the container). So I can simply create and modify the files/incidents via a script or manually. It seems the current statusfy commands are however not suited for this:Īt least to my current knowledge, i would implement containerizing by mounting the "content" folder with the incidents to the host. What problem does this feature solve?Ĭontainer will be the "only" way to run applications in the future.
#Statusfy car start how to#
Create a section in the documentation how to best run in a Docker Container Environment.
0 kommentar(er)
