Deploying in 2017


  • Winner of the 2016 Presidential Election

    So at work I have to manage multiple projects. That alone is pretty nifty especially since my professional experience is pretty limited.
    Now those projects are supposed to go on different servers every once in a while.
    So far I have written my own bash / python scripts contained in a Setup-folder to make that work.

    Now my bossman is asking me to look into making deployment of the projects simpler.

    As far as I can tell all deployment goes to Linux Systems. Though I can't promise that that's going to stay that way

    My boss suggested Docker but since he chose MongoDB already I feel like getting a second opinion

    Here is what I need:

    • Needs to be able to install a database if such a thing doesn't exist
    • Needs to move some files into different folders
    • Would be great if it created services for me
    • Should probably download python requirements. Though I can use pythons setuptools for that, I guess.
    • syslinks or whatever would be great

    Is there something out there that fits these requirements and doesn't require a masters degree in advanced phsyics to be used?

    Thanks in advance :)

    Filed Under: While I am at it, I'd like a pony and a raise. Thanks :trollface:


  • sockdevs

    @Kuro It does sound like Docker is a realistic option, but I'd wait for more knowledgeable people to weigh in first.


    @Kuro said in Deploying in 2017:

    I'd like a pony

    So long as it isn't Twilight Sparkle

    @Kuro said in Deploying in 2017:

    and a raise

    /me raises Kuro on a scissor lift


  • Winner of the 2016 Presidential Election

    We use Octopus Deploy where I work. You can give it Nuget packages (which are basically just zips of the files you want to deploy) and tell it where to deploy them, add scripts in Powershell and a few other languages, run SQL scripts etc. There are community developed steps as well

    It seems a bit Windows centric, but that might be because all of our servers are Windows so that's how it's been set up



  • Is anyone going to mention buildmaster?


  • Winner of the 2016 Presidential Election

    @PleegWat Has anyone here actually used it for real-world projects?



  • @asdf Not me. We've got the NIH bug something fierce (though a lot of our corporate overlord homebrew predates generally available alternatives)


  • Winner of the 2016 Presidential Election

    @PleegWat said in Deploying in 2017:

    We've got the NIH bug

    Well, deploying applications is hard, and the requirement vary a lot; so it kinda makes sense to write your own tools. I don't know whether I'd trust the magic of an existing tool myself.


  • Winner of the 2016 Presidential Election

    @asdf said in Deploying in 2017:

    @PleegWat Has anyone here actually used it for real-world projects?

    @ben_lubar, maybe?



  • @Dreikin said in Deploying in 2017:

    @asdf said in Deploying in 2017:

    @PleegWat Has anyone here actually used it for real-world projects?

    @ben_lubar, maybe?

    I've got it set up for DFHack builds on my computer and the Inedo instance is set up for all the Inedo products, extensions, and websites. thedailywtf.com is deployed by BuildMaster.



  • @Kuro have you looked into Ansible? Looks very good for your usecase.

    You can combine that with Docker if you wish.


  • :belt_onion:

    I'm not sure I'll be of much help, but there's a few questions which don't seem to be asked / answered yet:

    • How often does it need to be deployed and how long would it take to deploy by hand? There's some XKCD table which puts frequency vs time to complete to give you an idea how much you can save by automating these tasks.
    • Is this on company hardware, some cloud provider, remote on-site installs, or a combination? At work we're heavily invested in Azure, but they make some things oh-so-easy.
    • Who needs to do the deployments, and what is their definition of "simple"? A well-written step-by-step guide might be better than a cobbled-together script.
    • Can you version everything? I don't recall pypi so well from that one time I read about Python, I hope it allows you to point to a given version?

  • Winner of the 2016 Presidential Election

    @JBert said in Deploying in 2017:

    How often does it need to be deployed and how long would it take to deploy by hand?

    Hell if I know. This is not my decision. As I said, I usually just drop some files in a folder and run them on install time. But that is not automatic enough right now.

    @JBert said in Deploying in 2017:

    Is this on company hardware, some cloud provider, remote on-site installs, or a combination?

    I'd say combination? It shouldn't really matter, though, right? Installing your own things on a system is pretty much always the same afaict

    @JBert said in Deploying in 2017:

    A well-written step-by-step guide might be better than a cobbled-together script.

    Been there done that. I did drop that next to the files to run on install until now.

    @JBert said in Deploying in 2017:

    Can you version everything? I don't recall pypi so well from that one time I read about Python, I hope it allows you to point to a given version?

    yeah, pretty sure setuptools can do that. I know pip can load extensions by versioning (so just copying pip freeze into a file and loading that)


    To everybody else. Thank you for your suggestions.
    I'll probably have a look at some of the suggested things during worktime throughout the week.

    Filed Under: :thanks:



  • @JazzyJosh said in Deploying in 2017:

    @Kuro have you looked into Ansible? Looks very good for your usecase.

    You can combine that with Docker if you wish.

    Yeah, I was thinking that a simple server/configuration management tool would work well. The requirements list simplifies to pretty much just installing packages and copying files. I haven't used Ansible, only Salt and Puppet a little, but it looks like it should be pretty easy.



  • @Kuro said in Deploying in 2017:

    @JBert said in Deploying in 2017:

    Is this on company hardware, some cloud provider, remote on-site installs, or a combination?

    I'd say combination? It shouldn't really matter, though, right? Installing your own things on a system is pretty much always the same afaict

    Well....it could make a lot of difference depending on the sort of connectivity you have between the server(s) and wherever the stuff is coming from. This could easily be a serious problem for installing stuff to other people's servers.

    We're working right now to be able to have ssh connections between our customer's data center and our servers inside our network, which is going to make deployment automation a lot easier, not to mention possible.


  • Grade A Premium Asshole

    @JazzyJosh said in Deploying in 2017:

    @Kuro have you looked into Ansible? Looks very good for your usecase.

    Or Chef, or Puppet, or any of the other similar options.


  • Grade A Premium Asshole

    @Kuro said in Deploying in 2017:

    It shouldn't really matter, though, right? Installing your own things on a system is pretty much always the same afaict

    Oh, you're so cute.



  • Last time I had to do this, I made a node.js service which generates a bash script using an EJS template, then opens an SSH tunnel to target server, injects the script file and executes it, then the remote bash script occasionally pings back the server with progress updates.

    Don't do this.


  • sockdevs

    @cartman82 said in Deploying in 2017:

    Last time I had to do this, I made a node.js service which generates a bash script using an EJS template, then opens an SSH tunnel to target server, injects the script file and executes it, then the remote bash script occasionally pings back the server with progress updates.

    0_1498070504354_Do Not Want (1).jpg


  • Grade A Premium Asshole

    @cartman82 said in Deploying in 2017:

    Last time I had to do this, I made a node.js service which generates a bash script using an EJS template, then opens an SSH tunnel to target server, injects the script file and executes it, then the remote bash script occasionally pings back the server with progress updates.

    Don't do this.

    0_1498071004998_b5a226a8-6ebc-435f-a63c-26cf337b06c5-image.png


  • :belt_onion:

    @cartman82 said in Deploying in 2017:

    Last time I had to do this, I made a node.js service which generates a bash script using an EJS template, then opens an SSH tunnel to target server, injects the script file and executes it, then the remote bash script occasionally pings back the server with progress updates.

    Don't do this.

    This is more or less what Ansible does beneath the covers, though they obviously did all the programming and debugging work for you. There's also a bit more infrastructure to run a "script" on a whole batch of machines.

    Salt, Chef and Puppet simply have that command-generating service running on each managed server and then "pull" the script from a central server, whereas Ansible uses a "push" mechanic.



  • The one thing I dislike about Ansible is that you have to specify the hosts file each time you use ansible-playbook (unless, of course, you alias the command)


  • :belt_onion:

    @JazzyJosh When I used Ansible a while back we had the inventory saved in /etc/ansible/hosts so that you don't need to specify the inventory at all times, just the target group is enough.

    At one point somebody replaced it by a script to connect to some external source. It was then just a matter of spitting out JSON from the script as Ansible can parse that as well.

    Making aliases which invoke ansible with different inventories is still interesting though, you can then use multiple inventories which in turn allows to reuse group names.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.