Lucian Maly

Hi Jamie,

Thank you for your reply. We have a local cluster that gathers absolutely all telemetry (we do not filter out anything!) and then we alert only on few important things - this took a while to get right. I like your point of view from the SRE perspective, we tend to ignore that sometimes.

Just FYI community seems to be recognizing 3 different types of "important" metrics and that matches wit what you are saying:

1. The USE (Utilization / Saturation / Errors): great for low-level metrics and often used in the context of performance engineering and root cause analysis = SDLC school

2. The RED (Rate / Errors / Duration): focus on the number of requests served, the number of failed requests, and how long requests take; useful for many application-level cases = SRE school

3. USE+RED combined - latency, traffic, errors, and saturation etc.

Cheers

Hi Jamie,

Metrics-style telemetry is about using numbers - e.g. value of rates, timers and so on, to get the feedback about what’s going on in your system. But How do you know what metrics should you be looking for (for example in Kubernetes, there are hundreds of different metrics). What's your golden rule?

Many thanks for hanging out on CodeRanch.

Welcome, Jamie!

Fantastic, thank you for promoting me to Ranch Foreman

Congratulations to all the winners and thanks for having me!

Yes, you could scan image at night or you can also scan containers at runtime instead - e.g.:
sudo oscap-docker <CONTAINER_ID> xccdf eval --report report.html --profile ospp <PATH_TO_PROFILE>

Hi Tangara,


Yes, there are multiple Red Hat certifications covering Ansible. All of these are very hard and long (4 hours), hands-on exams:
1) Legendary RHCE is now based on Ansible
2) Red Hat Certified Specialist in Services Management and Automation
3) Red Hat Certified Specialist in Advanced Automation: Ansible Best Practices

As for Terraform, there is only one - HashiCorp Certified: Terraform Associate.

I have passed some of these, so happy to discuss further.

Hi Sai,

This is an excellent question. The dockerized version of OpenSCAP is not covered in my liveProject, however in principal it is almost the same command-line tool and integrates nicely with CI/CD pipeline. What you would do once your Docker image is built (e.g. using the Containerfile/Dockerfile) is to run in your CI/CD step:
oscap-docker image <image name> <oscap parameters>
Some of the parameters would include e.g. the OpenSCAP profile and report/results file (that bit is covered in my liveProject). Based on the exit code of oscp-docker or the results file, your CI/CD would perform other steps (e.g. stop everything if there is vulnerability).

Michael Stone wrote:

Lucian Maly wrote:Many thanks for the introduction. I'm happy to chat about my liveProject.

For those who don't know what is Manning's liveProject: liveProjects are a type of self-paced learning and are based on real-world challenges and require hands-on work - you’ll solve practical problems, write working code, and analyze real data etc. Manning Publications believe that the best way to master a subject is by creating something that really works and I agree! Note: As a part of the purchase, you will get access to multiple resources/Manning books that will help you finish the project.

Hello, Lucian!

Since the focus in on secure, does your book walk us through how to make good use of secrets native to Ansible, and Terrafrom, or does it also teach us how to employ other methods using tools such as Keycloak, or integrating with other external tools to accomplish the same?

Thank you very much,
MS

Hi Michael - same goes for you, your chances of winning are higher, if you create a separate thread with your question:-)

There is a section which talks about using Ansible Vault to store sensitive information that is used by Ansible, but I don't really talk about secrets in Terraform. Happy to explore that with you in a separate thread.

tangara goh wrote:

Lucian Maly wrote:Many thanks for the introduction. I'm happy to chat about my liveProject.

For those who don't know what is Manning's liveProject: liveProjects are a type of self-paced learning and are based on real-world challenges and require hands-on work - you’ll solve practical problems, write working code, and analyze real data etc. Manning Publications believe that the best way to master a subject is by creating something that really works and I agree! Note: As a part of the purchase, you will get access to multiple resources/Manning books that will help you finish the project.

Hi Luican,

Not sure if this is the place to ask a question but I hope that this question will get me win a copy of your book.
I'd like to know if you encourage people like me who are still trying to even able to do HackerRank question well, to start learning ansible ?
Thanks.

Your chances of winning are higher, if you create a separate thread with your question:-)

Patrick Dung wrote:The main problem I had heard is that TF needs to be updated when AWS made changes (API change?) or release a new service.
TF needs to be updated before it could utilize or adopt the changes in AWS, where AWS CF is native.
I also remembered somebody said it's ok to use TF for other public clouds and better to use AWS CF on AWS.

The statement "TF needs to be updated every time AWS changes something" is not entirely correct. First of all, the API of the core services does not change that often, and if it does it is backward compatible. So it is usually the new services that might need your Terraform provider to be updated from time to time (and funnily enough, there were cases were Terraform implemented those even before AWS CloudFormation). Another thing you should know is how providers or any other extendable code work in Terraform - it is heavily "pluggable" via SDK. What it means is, Terraform itself does not actually come with any providers out of the box and adding/updating the provider is very simple - see this link: https://www.terraform.io/docs/extend/plugin-types.html

Essentially, these two commands are the most important ones:
$ terraform providers <dir> $ terraform init -upgrade <dir>

Hi @Patrick Dung,

This is a never ending war... Neighbour of mine (cloud engineer) would say "always use the native tools". However, he only works in AWS environment and he is a big AWS fan, so bit biased.

I like to select the tool depending on the requirements for every project. If there is no particular reason to use native tool, I tend to use Terraform. I don't have anything against CloudFormation and used it personally many times in the past, HOWEVER, Terraform is way more than just agnostic IaaC (infrastrcuture as code) tool. Terraform was created by Mr. Hashimoto primarily as a "state management tool" and that is a strong decision point, because you cannot store the state of your infrastructure on your local drive, when you use CloudFormation. Terraform is also often faster than CloudFormation when it comes to supporting new AWS features. On top of that (might be the strongest reason to use it), Terraform supports other cloud providers as well as 3rd party services - so with very little change in your code, you can create the same/similar resources on a different cloud provider.

Many thanks for the introduction. I'm happy to chat about my liveProject.

For those who don't know what is Manning's liveProject: liveProjects are a type of self-paced learning and are based on real-world challenges and require hands-on work - you’ll solve practical problems, write working code, and analyze real data etc. Manning Publications believe that the best way to master a subject is by creating something that really works and I agree! Note: As a part of the purchase, you will get access to multiple resources/Manning books that will help you finish the project.

Apparently the author has written around 250 tests for the programs in the book, which is really amazing, but it also means that you’re going to encounter many failed tests :-D

Thanks Ken

Looks like there is a section in the book - "Setting up your environment"