Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Dec 30, 2019 15:59:16 GMT
Other sensible thing to do would be to use something like TravisCI like we do on the main TFM repo to actually drive the builds, that way every "Production Ready" build has been properly built on a known piece of infrastructure and not just someones local PC. Yes, an actual production system as opposed to people bashing together binaries on their computer and FTPing it into a server like monkeys. Yeah, just some sort of CI Pipeline. The issue comes with how you get the JAR out of it, because you can't host it or share the JAR anywhere, so you'd need to figure that much out...
|
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Dec 30, 2019 16:02:15 GMT
i'm pretty new to using docker, but i'll try to see what i can do in order to make it work Docker would provide a container containing the Minecraft server as an application, but you would want to use something like Puppet (I think Wild1145 knows some other tools which are targeted for Minecraft) which configures that container so that it has all of the necessary crap for automatically deploying the full server. This type of system is also useful with a server control panel, which I know we have, they go hand-in-hand and you can use a web control panel to configure the server you want to deploy (or you can have it just be completely automatic and update the entire server upon a new GitHub release or master branch update), or configure a web control panel to use to manage the container/server. This type of stuff is useful to learn not only to improve the server but also useful later on if you want to work a job which utilizes a production/deployment system, which are many. So personally I'm not a major Docker Fan, I don't like it very much. Puppet is probably more appropriate for Config I've found but technically can achieve state management, but it's a bitch if you fuck it. Personally I've gone down the Ansible route, you can use it to configure Docker and all that crap if you want but the important thing is it is not state management, it's one shot setups and synchronisations. We use it in work for our mission critical systems as we can test the ansible playbook in dev and that same playbook will build the identical environments the whole way through to OPS. I posted a thread about how I'd started to build one for my own MC server project that I then dropped as other things came up, but that's probably more of what I'd look at. To go back to the original point though, just having a stable build process is probably something that's more important right now, having set guidance on how stuff should be built and all that would at the very least mitigate the issue raised originally, and then how you do proper CI / CD in the future is something you can always investigate. Edit - This was the thread I'd made. I'll pick it up in the new year but it should give you an idea of the power of Ansible if used properly totalfreedom.boards.net/thread/65284/ansible-automation
|
|