|
I too was hoping for a thread like this! For anyone that uses Ansible - do you have experience using the Docker module? If so, how do you get it to start a container and then issue a command to it? I have a small project to get mongo installed, and I can get the container started and then log into the box/container to do stuff. However, I'm trying to get replication set up on it, and when I try to actually issue commands via the module, it just seems to kind of die.
|
#
¿
Jan 23, 2015 02:26
|
|
|
|
| # ¿ Apr 29, 2024 06:39 |
|
|
EAT THE EGGS RICOLA posted:Docker has had a few crazy bugs recently that would make it insane to use in production, hasn't it? I can't argue with this, it's neat tech but still a bit premature for my taste. However, I'm being paid to make that happen(in fact I'm just replacing a manual process with an Ansible script to set up these containers). I find the Ansible module to be a bit limited, but I fully expect I just don't entirely know what I'm doing. This is also on CoreOS, but that doesn't make a huge diff, all the action is happening in the container. Anyway I'm going to keep on truckin, I just don't know if there are any obvious mistakes I'm making.
|
|
#
¿
Jan 23, 2015 04:54
|
|
|
revmoo posted:I've used Jenkins a few times and finally this time around fallen in love with it. It takes a lot more hacking and configuration, but once you have it running it's awesome. I think the best thing about it is that its popularity means there is a plugin for everything. I just started at a new place and we do exactly the same thing - Jenkins runs Ansible playbooks, which makes it super easy to clone and modify jobs without having to worry about a ton of config being stuck in there and needing to be changed. Need automated deployment in dev, but push-button for prod? Just clone dev, change the inventory file, and remove the repo polling or post-commit hook. Ansible manages the complexity well, and I can run playbooks by hand and throw in some extra command-line variables to debug if needed. It's a really nice workflow. Is this the right place for AWS chat? My employer is primarily an AWS consultancy/devops shop, and we dig deep into the guts of Amazon's offerings. Is this perhaps better suited to its own thread? xpander fucked around with this message at 19:07 on Sep 23, 2016 |
|
#
¿
Sep 23, 2016 19:02
|
|
|
fluppet posted:If you're using the aws codepipeline tooling I'd be interested in hearing how that's going I think we actually are, but it's a different team. I will look into that. Meanwhile, here's my AWS megathread: http://forums.somethingawful.com/showthread.php?threadid=3791735.
|
|
#
¿
Sep 23, 2016 21:41
|
|
|
Cancelbot posted:Have any of you done a sort of "terms and conditions" for things like cloud adoption? Our internal teams are pushing for more autonomy and as such are wanting to get their own AWS accounts and manage their infrastructure, which in theory sounds great. But when they need to VPC peer into another teams account or connect down to our datacentre something has to be in place to ensure they're not going hog wild with spend, not create blatant security risks etc. I am loathe to use it unnecessarily, but this is where the "D" word comes in. The companies I've consulted for are inserting "devops" there to have some automation in place to reflect the policies laid out from management. There's nothing magical about it, but in AWS, a simple answer is to have something like Service Catalog products ready to go with choices for things like instance class and VPC. This works pretty well for SMBs, or as a starting point for any sort of self-service initiative. Scaling that up, I helped implement an API for a customer who wanted to be able to create new VPCs/AWS accounts with a single HTTP call, we used Step Functions to handle the workflow. Of course they had rather heavy IAM in place to safeguard these new treasures. I can expound a bit more on this stuff, but I'm limited somewhat by NDA. The bottom line is that you need to have those policies reflected by automation/code or else they aren't worth a hill of beans. Anything not enforced in this way leads to keys on Github and $68k miner happy hour. Not only that, but self-service avenues mean that you can make it easier for teams to adopt those methods, which reduces the burden on your ops team to provision resources and gives them more time to roll out cool stuff like this.
|
|
#
¿
Jun 28, 2018 20:39
|
|
|
Umbreon posted:If anyone here has some spare time to answer: I'll answer your question by describing my job and providing possibly useless colour commentary! Hopefully this will give you a glimpse of what you're after, as I'll try to tailor it to your background(saw your other post). I work for an MSP("managed services provider" aka cableco), as an "AWS Developer". My team is responsible for implementing architectural best practices to drive the corporate AWS strategy, as well as evangelize cloud stuff to other teams/business units and provide them with general guidance for anything related to the cloud. We're primarily an AWS shop(like 95+%) but this could easily apply to Azure/GCP/etc in the future. I've only been on the job for a month, so I can't give the long tail of what it's like in particular . But in a previous role I was consulting to this same type of organization, so I have a decent base of reference. The majority of my time is hands-on-keyboard, writing software and templates related to cloud infrastructure management. I've also had a couple of days in workshops related to some initiatives we're trying to move forward on. Inevitably there will be a ton of troubleshooting at certain points, so putting on my systems engineer hat will be a well-practiced manoeuvre. Haven't had to do much on the evangelism tip, but I suspect that will ramp up as I become more familiar with other teams and people, and we get more automation written. Speaking of automation, that's a big focus of the team: getting tons of stuff moved away from manual touches to a state where they're largely or completely automated. This is obviously a lifetime's work, but there are some nice wins that large enterprises can afford to spend the money and time on. Doing things like automating the creation of CI/CD pipelines, the notification and remediation of "guard rails" noncompliance, internal tool building and packaging, etc can all be real force multipliers at scale. You don't have to be a software engineering genius to do this work(I'm certainly not), but solid scripting skills in something like Python or Ruby(and bash too if you have *nix in the mix) are essential. Having the understanding of a systems engineer is important, as we might be needed to troubleshoot an issue relating to on-prem systems or access, or architect a solution and take into consideration the potential complexities at a lower OSI layer or some poo poo. In general, I've found the "devops" space to be one that finally rewards generalists who are able to go deep in particular places. The real issue you're likely to encounter is, as others have mentioned, the absolute uselessness of many words orbiting the area. If you don't know what to look for, a particular position or path might seem worthwhile but actually just embody the kinds of horrors papered over by buzzword bingo. The posting for my position was remarkably terse, which in itself was promising, and I was able to telegraph a lot of info based on what they did provide. In terms of the difficult parts of the job: the #1 thing might be the constant pressure to learn and stay on top of new developments in your org's particular industry as well as tech in general. If you aren't given time on the company dime to do that learning, then they had better be paying you drat well. I heard it brought up that my company is pushing for people to be able to develop their own learning plans to move both forward and laterally in their careers/positions, but without a clear dedication to carving out the time to do that. Even with the internal support to do so, if you are somehow without the drive necessary to do that learning(whether you aren't the type of person that's naturally curious about the tech, or can't otherwise externally motivate yourself) then it's possible you'll follow the path of the dinosaur like many of the jobs people like me make obsolete! Certainly the best places reward that kind of curiosity, and the worst have a sort of slavish devotion to "learning culture" that's hollow and misunderstood. Well that's a lot of words on the topic, so I'll wrap it up here. But do feel free to come back with anything more specific, and others can probably chime in with more wisdom than I have on offer.
|
|
#
¿
May 5, 2019 20:04
|
|
|
JHVH-1 posted:This is neat. Was watching aws twitch stream and never heard of it before. https://github.com/awslabs/aws-cdk Another team at my place of employment uses it and speaks the world of it. My own crew isn't quite ready to put all our eggs in the CDK basket yet as it can't guarantee forward-compatibility at this point, but we're watching it with much interest.
|
|
#
¿
May 31, 2019 06:04
|
|
|
Nomnom Cookie posted:I'm on "the DevOps team", so... If they're looking for a certain APN partner-level status, likely they're after Pro certs, not DevOps Engineer specifically. Probably a good idea to check on that though, and whether they still need people with Associate-level certs as those are much more easily obtained. I just wrote this exam for the first time a bit over a week ago, having previously written(and failed) the SA Pro exam. I can guarantee you aren't going to walk into that and pass if you haven't used AWS in a year. While some general devops principles apply, obviously this is AWS-centric. DevOps Eng Pro goes deep, whereas SA Pro is wide on topics(or so I've heard it described, and would agree). I had questions on Step Functions, Lambda, API Gateway, Trusted Advisor, Macie, CodeBuild/CodePipelineCodeDeploy, Cloudwatch, Kinesis, DynamoDB, along with tons on S3/EC2/ASG/VPC/etc. Definitely get more info on what your org needs, then form a plan!
|
|
#
¿
Feb 5, 2020 19:57
|
|
|
|
| # ¿ Apr 29, 2024 06:39 |
|
|
CyberPingu posted:Hi all, Good news! There's a Config rule that'll do exactly this: https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html
|
|
#
¿
Jun 4, 2021 19:25
|
|