+1 for using hadolint! I have been using it for ages, and I highly recommend it. I also sometimes write some Goss tests, and even run Trivy at the final stages of the container build and delete them once done in the same layer. It takes about 10 seconds or so longer to build the container, but its baked in and helps you catch issues before pushing the container.
I wish I knew this existed the other day, I spent about 10 minutes tracing all the crapware creative cloud had installed onto my macbook and deleted it. Some of it was using 5% cpu occationally, to do what?
This directly references the public archive team effort, not evidence of a the hack. The comment and “story” that is circulating seems like it’s just taking the public archive team effort and adding some sort of falsehoods around a hack where they were also pulling data via admin functionality. I can’t find any other information about the admin hack apart from this potentially false story.
I can't validate anything else in this twitter post. The administrator accounts part all seems fake, unless anyone has found the rest of the content or has a better source?
Kind of. Who ever is on call should be able to deal with the issue. Your highest level of escalation should be your engineering manager, VP of engineering or CTO. Your product manager should care about team health checks, and how much you are getting paged, then prioritise engineering time to reduce it. Its about collaboration. If it doesn't work out, maybe you could put your product manager shadow on call too. I haven't ever had to do this, but it could be fun.
If your writing software or operating infrastructure, you need to be on call. Otherwise you don’t have skin in the game. It makes you a better engineer, and at most places increases the quality of your software in two ways. One, you don’t want to get that call at 2am, so you think more about reliability, edge cases, writing playbooks etc. Secondly, when things do go wrong, you perform a post mortem and you get the action items in your stream of work. Additionally you should always track on call stats and use it as a metric in your team health checks. If people are getting called a lot out of hours, it’s time to pull the cord, and sort it out.
I like this. I am a firm believer of keeping things simple until you need them. Service meshes have their place, and they are useful when your running at scale, or you really need all the features, but most people don't need them. You often hear people asking for enhanced telemetry, or that they need it to load balance grpc. The simple solution is to fix the telemetry in your app, and get your grpc client to use a headless k8s service and set it up correctly. This is a bit more involved upfront, but its better than maintaining another tool, and adding the extra complexity to your infra.
I agree. However for a lot of people, their workloads have been running on x86 forever, maybe their production instances are not reproducible, and with combinations of cpu/memory/io being limited, at scale this could cost $$$. I’m just curious to see how this will pan out.
Is it going to be interesting to see how new Apple machines running ARM based processors plays out.
Writing code, and building docker images locally on ARM and building and running the same code on X86 in production could potentially, in some circumstances cause some issues. If not, it's a bit of a pain to potentially build and publish x86 and ARM images so that people can run them anywhere (Some projects are already doing this). Running production on ARM could work if you wanted to, but right now the instance types are very restricted in terms of different combinations of cpu/disk/io.
1. I usually advise people to raise an ADR when they are adding new component to a system, a new technology, or really anything that they feel needs context and want to have a discussion about. Usually I advise either making a pr in the repo for that component (this can be in #1 with the first commits of code) or in a centralised docs repo when you are adding new technologies to your stack or setting standards etc.
2. I have used them in place of RFCs at a couple of places. Generally I would write code or docs alongside an ADR and use the comments in a pull request to get a review on it, and try to improve the PR with the comments. If there is a consensus in the PR from enough people it would get merged in, if not i would take it to an appropriate forum to discuss it (guild, standup, meeting etc).
I have found creating a couple of ADRs in a team and getting that team to participate in the process first is a great example to showcase to an organisation at a show and tell, lunch and learn etc. Adr-tools is a great tool to help create an ADR and provides a good template too!
I am presuming they are having some database issues. In their last incident we saw them mention running out of database connections. They also have some planned downtime when they are planning on switching quay to readonly whilst they perform some actions. Perhaps resizing their master DB? Its hard to tell, but either way this is quite unacceptable for such a big service that so many rely upon and pay for.
Everyone has avoided running tiller server for a while and ran it locally (tillerless) instead. It serves the same purpose and works around the huge potential security issues tiller causes when ran in the cluster.
I think so! I am reluctantly using it currently, it’s simplicity is great if your just building, testing and deploying to a couple of environments. So maybe it’s just good enough for most, and that’s fine. However, It’s practically useless, and wholly frustrating as soon as you want to build any remotely functional CD pipeline. Fan out, fan in? No chance. Build step history? Nope. Random step failures and wait times to pull images? Yeah, loads of them. To top it off, it’s all part of Bitbuckets incredibly slow platform where pages take up to 10 seconds to load. My favourite part of it all the discussion forums and 7+ year old feature requests for things like commit signing.
I am looking forwards to digging in to this a bit more and figuring out how this compares to Istio. I am guessing integration with AWS services such as X-ray and Cloudwatch/logs are the selling point. Still, I am a bit weary about configuring things that run inside your Kubernetes cluster through amazon apis, and not k8s resources. However, you could easily create a custom resource for this. Maybe that is to come?
EKS is still young and they are yet to figure a lot of things out, from what i've seen, the roadmap is promising though. I have been working with it a lot, kops still wins for small/medium workloads in production, but I doubt for much longer.