|
What do you guys consider the most painless way of deploying docker containers to AWS? They have something called ECS and Elastic Beanstalk which seems nice, but is it actually good to use when you just want to automate everything or should I look at a different automation layer like (random selection) Convox or Rancher?
|
#
?
Jan 7, 2016 12:01
|
|
|
|
| # ? Apr 18, 2024 10:51 |
|
|
Sagacity posted:What do you guys consider the most painless way of deploying docker containers to AWS? They have something called ECS and Elastic Beanstalk which seems nice, but is it actually good to use when you just want to automate everything or should I look at a different automation layer like (random selection) Convox or Rancher? It takes less than 15 minutes to get set up on though, so you might as well just give it a shot. If you're not tied down to AWS, Google Container Engine is a pretty well-flushed out container grid.
|
|
#
?
Jan 8, 2016 00:21
|
|
|
Elastic Beanstalk (EB) wraps the EC2 Container Service (ECS), OpsWorks and EC2 management. It'll provide you the greatest level of abstraction, but with that you sacrifice the ability to customise your setup. Some of the core wins for EB are docker support, blue/green deploy, versioning, migration, load balancing and health monitoring. If you want to avoid nitty-gritty, you can follow a guide like this and get up and running relatively quickly. However, if you want to customise anything on AWS outside of EB, you'll soon be poking around OpsWorks and ECS, and might find you need to drop EB and configure services more directly.
|
|
#
?
Jan 8, 2016 03:09
|
|
|
Interesting, thanks! I'm not really tied down to AWS, I have a few things there already but that's only stuff like static sites hosted in S3 and some Route 53 DNS stuff. My requirements are fairly simple, I just want to run a dockerized Java app that I can update without downtime (so behind a load balancer that I can autoregister the app with), a hosted database (preferably Postgres, though I guess Google's MySQL-based one is also fine) and lots of object storage that's easily accessed through HTTP, like S3. If I can automate as much of the devops works as possible that would be nice. I've done Chef stuff in the past and got everything to work but it's really too much hassle for what is going to be (hopefully) a fairly simple service. Ideally I'll run a simple Jenkins instance at home, build stuff on that and have it deployed automatically on success. AFAICT that'll mainly leave me with AWS, Google or Azure, since other options require me to do a lot of the infra management myself. Do you guys have a preference for one of these three managed options? Edit: Looks like the free tier of Codeship in combination with AWS will work for me. It'll allow me to commit to BitBucket and have it autodeployed. Seems good. Sagacity fucked around with this message at 15:11 on Jan 8, 2016 |
|
#
?
Jan 8, 2016 11:55
|
|
|
Sagacity posted:AFAICT that'll mainly leave me with AWS, Google or Azure, since other options require me to do a lot of the infra management myself. Do you guys have a preference for one of these three managed options?
|
|
#
?
Jan 8, 2016 18:49
|
|
|
Any advice on hiring a devops person as a manager who has done related work (development, systems administration) but not the devops role specifically?
|
|
#
?
Jan 14, 2016 01:14
|
|
|
I think the key difference between sysadmins and devops folks is the approach to the problem. Sysadmins fix things so they aren't broke. Devops types recast the system so that problem will never happen again in a way where you've got revision history and rollback baked in. The interview questions I'd start with are: # What is your line between "this is a manual process and 'we must script this'" -- devops should answer "what kind of crack are you smoking to have a manual process; script all the things." # What is your favorite VCS? -- devops should have an educated answer here. # Why are orchestration systems better than shell scripts? -- devops should have an educated answer here too, traditional sysadmins who get orchestration systems will note something like "yeah, fewer lines of bash"
|
|
#
?
Jan 14, 2016 01:22
|
|
|
wins32767 posted:Any advice on hiring a devops person as a manager who has done related work (development, systems administration) but not the devops role specifically?
|
|
#
?
Jan 14, 2016 02:26
|
|
|
Vulture Culture posted:I swear to God I'm going to lose my poo poo and harpoon the next person who refers to "devops role." The very idea of a DevOps role is completely antithetical to DevOps. What a wonderful, productive comment. I'm certainly illuminated by it.
|
|
#
?
Jan 14, 2016 02:33
|
|
|
wins32767 posted:What a wonderful, productive comment. I'm certainly illuminated by it. DevOps is a culture shift toward fostering communication between developers and operations. That's it. For some reason, people call developer roles with a focus on automation of operations tasks "devops". I gave up fighting against the name a while ago.
|
|
#
?
Jan 14, 2016 02:36
|
|
|
Ithaqua posted:DevOps is a culture shift toward fostering communication between developers and operations. That's it. Thanks, that's helpful. Our CTO and I are doing the operations now, so there is no meaningful daylight between operations and development, nor do we want there to be. What we do want is someone who has an interest in automating and managing our infrastructure as well as keeping an eye on our design and architectural choices with an eye towards making sure we're making decisions that result in infrastructure that isn't a nightmare to support in a couple years. It doesn't feel like an OG sys admin position (since we want them involved in design and architecture discussions) as well as automating the hell out of our infrastructure. If that's not DevOps, what would you call it?
|
|
#
?
Jan 14, 2016 02:44
|
|
|
wins32767 posted:Thanks, that's helpful. Our CTO and I are doing the operations now, so there is no meaningful daylight between operations and development, nor do we want there to be. What we do want is someone who has an interest in automating and managing our infrastructure as well as keeping an eye on our design and architectural choices with an eye towards making sure we're making decisions that result in infrastructure that isn't a nightmare to support in a couple years. It doesn't feel like an OG sys admin position (since we want them involved in design and architecture discussions) as well as automating the hell out of our infrastructure. If that's not DevOps, what would you call it? It's a developer position. All the developers should be contributing. You want to hire another developer, and some development tasks are infrastructure automation tasks. A devops role is just saying "let's totally automate the incredibly critical stuff and make sure the knowledge of that automation is understood and maintained by as few people as possible"
|
|
#
?
Jan 14, 2016 02:58
|
|
|
I think it's totally possible for there to be a DevOps role, because someone has to ensure the teams are adhering to the DevOps principles. I don't think it's enough for the managers to walk in and pronounce that "We're doing DevOps now. Dev, talk to Ops more often, and vice-versa." Someone has to keep the ball from getting dropped. Are Devs just as much on the on-call hook as Ops when prod falls over? Is Ops getting invited to Dev's design/architecture meetings? Is there shared ownership of the build-test-deploy pipeline, and who is responsible for maintaining and developing that? In the same way that there's a ScrumMaster who (amongst other things) is responsible for keeping the team aligned to Agile principles, there can be a "DevOpsMaster" who has a good understanding of the principles and the mandate to enforce them. It's not a given that this person would necessarily be a manager; in some companies, managers are more concerned with developing their reports' abilities than with deciding how they do their job.
|
|
#
?
Jan 14, 2016 03:04
|
|
|
Ithaqua posted:It's a developer position. All the developers should be contributing. You want to hire another developer, and some development tasks are infrastructure automation tasks. I'm struggling with the "all developers should be contributing" piece. I'm uncomfortable with junior developers being involved in operations on a production environment. It's asking a lot of them to master a language and framework, much less all of the other pieces of infrastructure that support a production environment. Dealing with production systems also requires a degree of judgement that takes a while (and dealing with multiple self inflicted problems) to develop. I can see the value of involving them in writing infrastructure automation. Being able to actually execute changes in production, especially in a highly regulated domain, feels different to me. Maybe I'm too old school.
|
|
#
?
Jan 14, 2016 03:18
|
|
|
wins32767 posted:I'm struggling with the "all developers should be contributing" piece. I'm uncomfortable with junior developers being involved in operations on a production environment. It's asking a lot of them to master a language and framework, much less all of the other pieces of infrastructure that support a production environment. Dealing with production systems also requires a degree of judgement that takes a while (and dealing with multiple self inflicted problems) to develop. I can see the value of involving them in writing infrastructure automation. Being able to actually execute changes in production, especially in a highly regulated domain, feels different to me. Maybe I'm too old school. They're not operating on production environments. They're writing automation scripts that will be well-tested and well-understood in lower environments before they ever touch production. You should, at the very least, have a staging environment that is 100% the same as production.
|
|
#
?
Jan 14, 2016 03:24
|
|
|
Ithaqua posted:They're not operating on production environments. They're writing automation scripts that will be well-tested and well-understood in lower environments before they ever touch production. You should, at the very least, have a staging environment that is 100% the same as production. Right, and the script writing is the part I'm fine with. But we need someone who is capable of getting on production environments that are having issues, figuring out what's wrong, and fixing the problem. That's the managing infrastructure piece I referred to.
|
|
#
?
Jan 14, 2016 03:30
|
|
|
If anything, DevOps could be someone's part-time role reviewing Pull Requests to your infrastructure automation scripts. Everyone should be encouraged to contribute. If the deploy fails due to someone loving up the Ansible playbook, blue/green rollout and integration tests should cover it.
|
|
#
?
Jan 14, 2016 03:39
|
|
|
The other thing about a systems/infrastructure specific job that's helpful from a management perspective is that it's not someone that the business folks are going to push to be working on features rather than infrastructure. Another developer could easily be pulled into feature work that has revenue figures attached "just for this sprint". I'm starting to see the value of developing a culture where all the developers work on infrastructure automation, but if I hire a developer I'm not going to have anyone to do the systems work we badly need until I change the whole culture.
|
|
#
?
Jan 14, 2016 03:39
|
|
|
wins32767 posted:Right, and the script writing is the part I'm fine with. But we need someone who is capable of getting on production environments that are having issues, figuring out what's wrong, and fixing the problem. That's the managing infrastructure piece I referred to. That's where an operations team comes in that actually has access to those machines. That's where the devops culture is in play. Instead of spending 3 days filling out request tickets and dealing with administrative red tape, the developer says "hey mr. ops guy, I need to get onto this box for a few minutes" and they work together to solve the problem. Except that should rarely happen, because nothing should be changing in your infrastructure that isn't source controlled, reviewed, and being promoted through several lower stages first for testing. wins32767 posted:The other thing about a systems/infrastructure specific job that's helpful from a management perspective is that it's not someone that the business folks are going to push to be working on features rather than infrastructure. Another developer could easily be pulled into feature work that has revenue figures attached "just for this sprint". It's up to the business to prioritize what they want delivered. If they want you to work on things that generate revenue and are willing to have you not working on infrastructure tasks to get it, you either shrug and do what they want or convince them otherwise.
|
|
#
?
Jan 14, 2016 03:43
|
|
|
minato posted:I think it's totally possible for there to be a DevOps role, because someone has to ensure the teams are adhering to the DevOps principles. I don't think it's enough for the managers to walk in and pronounce that "We're doing DevOps now. Dev, talk to Ops more often, and vice-versa." Someone has to keep the ball from getting dropped. Are Devs just as much on the on-call hook as Ops when prod falls over? Is Ops getting invited to Dev's design/architecture meetings? Is there shared ownership of the build-test-deploy pipeline, and who is responsible for maintaining and developing that? minato posted:In the same way that there's a ScrumMaster who (amongst other things) is responsible for keeping the team aligned to Agile principles, there can be a "DevOpsMaster" who has a good understanding of the principles and the mandate to enforce them. It's not a given that this person would necessarily be a manager; in some companies, managers are more concerned with developing their reports' abilities than with deciding how they do their job.
|
|
#
?
Jan 14, 2016 04:20
|
|
|
Ok, so let me change the conversation a bit here. What's the kind of skills that a small but very rapidly growing company should look for in their first hire in a role that needs to handle some operations work? There isn't enough work for a full time operations position, nor will there be for at least a year, but I want to lay a good foundation.
|
|
#
?
Jan 14, 2016 04:25
|
|
|
wins32767 posted:Ok, so let me change the conversation a bit here. What's the kind of skills that a small but very rapidly growing company should look for in their first hire in a role that needs to handle some operations work? There isn't enough work for a full time operations position, nor will there be for at least a year, but I want to lay a good foundation.
|
|
#
?
Jan 14, 2016 05:15
|
|
|
wins32767 posted:Ok, so let me change the conversation a bit here. What's the kind of skills that a small but very rapidly growing company should look for in their first hire in a role that needs to handle some operations work? There isn't enough work for a full time operations position, nor will there be for at least a year, but I want to lay a good foundation. What skills are missing in your current staff that are preventing your company from automating its deployment pipeline? Find someone with those skills. You're looking for someone to help the rest of you get on the same page so everyone can participate, not to do it for you. Vulture Culture posted:I swear to God I'm going to lose my poo poo and harpoon the next person who refers to "devops role." The very idea of a DevOps role is completely antithetical to DevOps. Right, the term is Thought Leader.
|
|
#
?
Jan 14, 2016 16:16
|
|
|
Erwin posted:Right, the term is Thought Leader.
|
|
#
?
Jan 14, 2016 16:53
|
|
|
Vulture Culture posted:What kind of stack? What duties are they going to be expected to perform? Who will they be sharing the load with? Rails/MySQL on Centos. To start with: Rebuild our infrastructure to be fault tolerant, get us tooling to support Continuous Delivery, troubleshoot and resolve production issues. Me and the CTO to start.
|
|
#
?
Jan 14, 2016 18:20
|
|
|
wins32767 posted:Rails/MySQL on Centos. To start with: Rebuild our infrastructure to be fault tolerant, get us tooling to support Continuous Delivery, troubleshoot and resolve production issues. Me and the CTO to start.
|
|
#
?
Jan 20, 2016 02:21
|
|
|
with some combination of heroku, circleci, and github you could get your setup running a poor version of continuous deployment in a few hours.
|
|
#
?
Jan 20, 2016 03:00
|
|
|
It's probably not a zero-effort thing to get the app working as a 12-factor app, but it's not exactly an ordeal either
|
|
#
?
Jan 20, 2016 03:33
|
|
|
I'm hoping this is the best place for this question. I'm trying to setup a small cluster to get a better handle on ELK and automation/management (using Ansible/etc). Right now I'm just running VMs on VMWare Player, and I have baby's first two machine cluster up and running. Is there a better tool I can use to accomplish this? Would something like Vagrant allow me to easily spin up machines (ideally five or so, I think), or should I just scale the VM setup?
|
|
#
?
Jan 25, 2016 05:25
|
|
|
Ben Grahams Ghost posted:I'm hoping this is the best place for this question. I'm trying to setup a small cluster to get a better handle on ELK and automation/management (using Ansible/etc). Right now I'm just running VMs on VMWare Player, and I have baby's first two machine cluster up and running.
|
|
#
?
Jan 25, 2016 06:41
|
|
|
Ithaqua posted:They're not operating on production environments. They're writing automation scripts that will be well-tested and well-understood in lower environments before they ever touch production. You should, at the very least, have a staging environment that is 100% the same as production. Just please, please don't do stupid poo poo like give your 1-month old junior developers full access to your deprecated server templating and environment system and set them off on their own without expecting something to go wrong. God, am I glad I have a job that knows what to do with me now.
|
|
#
?
Jan 25, 2016 15:08
|
|
|
Vulture Culture posted:Depends what you're trying to do. If you're looking to have a bunch of VMs set up so that you can test a bunch of different playbooks corresponding to various server roles, for instance, you might be better off with something like Vagrant and Test Kitchen with the Ansible provisioner. If you're trying to set up clusters of interrelated services, stick with how you're already doing things for your sanity's sake. I took some doing but I got my vagrant cluster up and working with ansible, it's pretty cool even if building a vagrant file to accomplish what I wanted wasn't as easy as I thought - thanks for the advice.
|
|
#
?
Jan 25, 2016 23:03
|
|
|
StabbinHobo posted:you'd rather pay a salary than heroku Working in a regulated domain has implications that makes going with Heroku a hard sell, both internally and to our customers.
|
|
#
?
Jan 26, 2016 01:59
|
|
|
There was noise a while back about Herokus performance with high traffic sites. I think it was with the site Rap Genius. Did that ever get addressed?
|
|
#
?
Jan 26, 2016 16:25
|
|
|
Thermopyle posted:There was noise a while back about Herokus performance with high traffic sites. I think it was with the site Rap Genius.
|
|
#
?
Jan 26, 2016 17:31
|
|
|
wins32767 posted:Working in a regulated domain has implications that makes going with Heroku a hard sell, both internally and to our customers. Try working in finance and insurance. Heroku, JIRA, and BitBucket were all banned until recently.
|
|
#
?
Jan 26, 2016 23:41
|
|
|
Pollyanna posted:Try working in finance and insurance. Heroku, JIRA, and BitBucket were all banned until recently. At my job Heroku is still banned. JIRA is hosted on premise so it's fine. BitBucket is marketed as a fork called Atlassian Stash if it's hosted on premise.
|
|
#
?
Feb 1, 2016 00:40
|
|
|
Stoph posted:At my job Heroku is still banned. JIRA is hosted on premise so it's fine. BitBucket is marketed as a fork called Atlassian Stash if it's hosted on premise.
|
|
#
?
Feb 1, 2016 14:40
|
|
|
Bhodi posted:You've got it backwards. Bitbucket is now the on prem stash replacement, called the same as hosted. Has a few new features, we upgraded last month. good luck, Bitbucket has been hot garbage lately. We're seeing 1 to 2 issues a week with issues around the API right now. Last Friday when you hit the merge button in the GUI it would go into an eternal spin and sometimes merge or sometimes not. If you are doing a lot of code reviews I would suggest you get fisheye/crucible to do those on as the bitbucket pull request page only works well with smaller pull requests from my experience.
|
|
#
?
Feb 1, 2016 14:54
|
|
|
|
| # ? Apr 18, 2024 10:51 |
|
|
What are peoples' thoughts on TeamCity vs Jenkins?
|
|
#
?
Feb 2, 2016 12:55
|
|