This course was created by HackerSploit. You guys can check out the HackerSploit YouTube channel to see more videos: https://www.youtube.com/hackersploit
How to get your test reports from a pod – Kubernetes
Hello guys, today I am going to post a workaround that I am doing to get test reports from a kubernetes pod that has terminated. If you run your tests in a kubernetes pod, you must know by now that you can’t copy your files containing your test reports from a terminated pod. Many people were complaining about and you can see there is an open issue here.
I am going to show an example of api tests with postman and newman where I run the tests in a kubernetes pod and in the same microservices cluster since there is no public api to access them.
Create a Job
- First you need to create a job and save it in a .yaml file, like the example below:
apiVersion: batch/v1
kind: Job
metadata:
name: api-tests
namespace: default
spec:
parallelism: 1
template:
metadata:
name: api-tests
spec:
containers:
- name: api-tests
image: postman/newman:alpine
command: ["run"]
args: ["/etc/newman/test.postman_collection.json","--reporters","cli","--reporter-cli-no-failures"]
restartPolicy: Never
- Then run on your terminal or add it to your jenkins file:
kubectl apply -f job.yaml
Or you can also create a pod
- You just need to add this command to your jenkins file:
sh "kubectl run api-tests -i --rm --namespace=${ENVIRONMENT_NAMESPACE} --restart=Never --image=${YOUR_IMAGE}:latest --image-pull-policy=Always -- run /etc/newman/${YOUR_COLLECTION_PATH}.postman_collection.json -e /etc/newman/${YOUR_ENVIRONMENT_CONFIG_PATH}.postman_environment.json --reporters cli --reporter-cli-no-failures"
Why not a Deployment ?
In the beggining of the implementation I first tried to create a deployment, but deployments don’t support the policy to never restart the pod, which means the automation would never stop running and you wouldn’t be able to copy the reports from the container.
Copy the reports
So, now that your tests have finished, you can see the logs on jenkins showing they passed (or failed), but you want to extract the report from the logs and have them in a html/json/any file, so you can archive or publish them. Doing this you would be able to see clearer what is the issue and keep easy to access the reports for each pipeline.
Well,kubectl cp doesn’t work like docker cp unfortunatelly. Once your pod is terminated, you are not able to access the reports or anything inside the pod. So, for this reason there is an issue opened on the kubectl github repository that is exactly about that, you can check the progress of the issue here.
Now how can you copy the reports from the container if you can’t access it after the tests are finished ? Well, there is not a perfect way, some people send the reports to S3, some people send the reports to their emails, but I did find better to save the report copying the html code from the logs and saving it in a file.
On your jenkins file you will have the command to run the pod with the tests and after you need to cat the html report generated to be able to get everything inside the html tag and saving it in a file:
sh "kubectl run api-tests -i --rm --namespace=${ENVIRONMENT_NAMESPACE} --restart=Never --image=${YOUR_IMAGE}:latest --image-pull-policy=Always -- run /etc/newman/${YOUR_COLLECTION_PATH}.postman_collection.json -e /etc/newman/${YOUR_ENVIRONMENT_CONFIG_PATH}.postman_environment.json --reporters cli,html --reporter-html-export api-tests.html --reporter-cli-no-failures ; cat api-tests.html | tee report"
def report = readFile "report"
def update = report.substring(report.indexOf('<html>'), report.indexOf('</html>'))
writeFile file: "${workspace}/api-tests.html", text: update
sh "rm report"
First, you need to cat the html report that your tests generated (remember to have this script to run the tests in your docker image or the package.json if you use NodeJs, this is just an example). You can see that you will need to grab everything between the html tags. You can do this using substring or awk, whatever is your preference. I am using substring on this example, but if you want to filter out using awk, the code should be something like this awk '/<html>/','/<\\html>/'.
After grabbing the html report, I am saving it in a file and deleting the previous report file that contained the whole logs from the kubernetes pod.
Not perfect, not happy about doing these kind of workarounds, but this is a way to avoid sending the files to S3 or any other place. Hope it helps !
Automated tests in a CD/CI pipeline
Good pipelines are stable and can support frequent and small releases. When building the pipeline you need to include not only the build and unit tests part, but also the e2e tests and even the smoke tests and deploy to all the environments, so you have as minimun as human interation as possible, avoiding releases to be deployed by mistake.
CD pipeline
Below you have an image of a simple pipeline where you have the Build, Deploy, Test and Promote/Release stages. Imagine a developer merging his changes to the master branch, triggering a new build on this pipeline. The CI job builds the application, deploy to the specific environment, perform some tests and if everything is ok, the changes are promoted to prod environment if you have a CD environment. If you have any issue in any of these stages, the CI job is going to be stopped and you will have a red pipeline in the history of this job. These basic stages could be followed like:
Build – The stage where you need to build your application, usually I run the unit tests here already.
Deploy – The stage where you are going to deploy your application, so this could be your dev environment or dev and qa environment at the same time.
Test – Depending of which environment you have deployed your application, you will decide what type of tests you are going to run, for instance: smoke tests for the Staging or the e2e tests for the QA environment.
Promote – This stage is where you are going to add the script to deploy your application to the production environment in case the tests passed.
Continuous Integration (CI), Continuous Deployment (CD) and DevOps have a common goal: small, frequent releases of high-quality software. Sometimes of course things happen in the middle of the way and you discover a bug after the deployment to prod, but as you have this pipeline with a CI and CD running, the fix will be deployed to prod as soon as it is fixed and there is no other new bugs. For this reason it doesn’t matter how your release cycle is, integrated automated tests is one of the keys to have a CI/CD job running and doing the job.
Having a continuous integration pipeline doing tests on all the environments after the deployment helps to get a fast feedback, reduce the volume of the merge conflicts, everyone has a clear view of the status of the build and a current “good build” is always available for demos/release.
Some test/general recommendations
Separate type of tests for each stage – If you have different type of tests running in your CI pipeline (performance, UI, security tests ), better to separate each of them in a different stage so you have a clear vision when one of the stages fail.
Develop your pipeline as code – This is a general advice as it has been a long time that I don’t see teams developing their pipeline through the UI on jenkins. Always create a .jobdsl containing the pipelines that your project is going to have and create/update them automatically.
Wrap your inputs in a timeout – In case you have a pipeline that demands user interaction at some point, you should always wrap your input in a timeout since you don’t want this job hanging there for weeks. I usually have these inputs on the last release stage (deploy to production)
timeout(time:5, unit:'DAYS') {
input message:'Approve deployment?', submitter: 'it-ops'
}
Refactor your automated tests – As any development code you need to improve your automation after working in the project and obtaining more knowledge about the product/project. So, to keep your testing efficient, you need to regular look for redundancies that can be eliminated, such as multiple tests that cover the same feature or data-driven tests that use repetitive data values. Techniques such as boundary value analysis can help you to reduce the scope to just the essential cases.
Keep your build fast – Nobody wants a release pipeline that takes hours to finish, it is painful and pointless. Try to trigger the minimum automated tests required to validate your build, keep it simple. Due to their more complex nature, integration tests are usually slower than unit tests. If you have a CD pipeline run a full regression on QA, but if you have a CI and a separate pipeline for the releases run only smoke tests on QA first and then the full regression on the deployment to prod pipeline.
Test in the right environment – You should have an isolated QA platform that is dedicated solely to testing. Your test environment should also be as identical as possible to the production environment, but this can be challenging. Honestly you will probably need to mock certain dependencies such as third-party applications. In complex environments, a virtualization platform or solution such as Docker containers may be an efficient approach to replicate the production environment.
Test in parallel – As speed is essential in a CI/CD environment, save time by distributing your automated tests on multiple stages. As mentioned earlier in this series, keep your automated tests as modular and independent from each other as possible so that you can test in parallel.
parallel {
stage('Branch A') {
agent {
label "for-branch-a"
}
steps {
echo "On Branch A"
}
}
stage('Branch B') {
agent {
label "for-branch-b"
}
steps {
echo "On Branch B"
}
}
}Include non-functional tests – Don’t think that regression tests is only about testing functional end-to-end tests, it takes a combination of automated testing approaches to confirm that your application is ready to release. Make sure you have a bit of performance tests running a happy path with concurrent users, also some security tests and of course the e2e functional tests. Exploratory testing can uncover defects that automated tests miss, but then this should have been done before during the feature tests not the release pipeline
Don’t rely only on unit tests – Unit testing doesn’t tell you enough about how that code will work once it is introduced to the production application. Integration of new or revised code may cause a build to fail for several reasons. Therefore, it’s important to run integration tests, regression tests and high-priority functional UI tests as part of the build verification process.
Resources:
https://www.cloudbees.com/blog/top-10-best-practices-jenkins-pipeline-plugin
AWS Online Tech Talks 2019
Hello guys, just came here quickly to share with you this link containing AWS presentantions for this year, some of them already happened, but you can register and watch the next ones for free, the link is below:
https://aws.amazon.com/about-aws/events/monthlywebinarseries/
How to test internal microservices in a kubernetes cluster
Hello guys, I have been working with kubernetes, docker, postman and newman a lot lately due some tests on internal microservices. To test these internal microservices I am running postman scripts in the same kubernetes cluster where the services are running.
Kubernetes is an open source container orchestrator, which means you can group together all the containers (services) that share information. You don’t need to expose their endpoints for them to be available among themselves. PS: This is just my brief explanation, but feel free to explore a bit more.
To be able to run tests on internal microservices that are inside a Kubernetes cluster I created a Postman collection and together with Newman run the tests pointing to these services without the need to expose the endpoints.
Creating the postman script
– You will need to have postman installed to create the script
– I am not going through the details of this part, because this is not the aim of this post, but after you create the script on postman you will need to export to api/collections folder.
– Also, you will need to export the environment variables that you create it and save it in the api/envs folder.
– You can see an example of the collection here and an example of the environment variable here. Remember that the hostname needs to be the name of the deployment of your service in kubernetes.
Creating the docker file
– I am using this docker image as base, but you can use any other, you just need to install newman.
– Then we need to build a Docker image containing the postman collection, environment and global variables, data files, etc.
– After this we need to create a jenkins file that will build and push the image to the docker hub, the best practice is you to have a separate pipeline just to build the image (so the tests contains just the tests and don’t take longer than necessary to run), but in this example I am going to have just a separate stage to build the image and another to run the tests.
dockerfile:
FROM postman/newman
WORKDIR /etc/newman/
COPY . /etc/newman/
RUN chmod -R 700 /etc/newman
Creating the kubernetes deployment
– Now we need to create the jenkins file to build and push the docker image to docker hub.
– You can get the full code here.
– But this is the important part, the command below will create a kubernetes deployment in the namespace and run the tests from the image that we have just pushed.
kubectl run microservices-tests -i --rm --namespace=${ENVIRONMENT} --restart=Never --image=${IMAGE}:latest --image-pull-policy=Always -- run /etc/newman/api/collections/collection.postman_collection.json -e /etc/newman/api/envs/${ENVIRONMENT}.postman_environment.json --reporters cli --reporter-cli-no-failures
microservices-testsis the name of the deployment that you are going to create.-iKeep stdin open on the container.--rmis the argument that says to delete this deployment once the command is finished.
--namespace=${ENVIRONMENT}is the name of the namespace (environment) that you will run this deployment, so it needs to be the same as your services are running.--restart=Neveris the argument that says to not restart the deployment once is finished. You don’t want your tests running over and over again forever.--image=${IMAGE}:latestis the image that kubernetes is going to pull.--image-pull-policy=Alwaysthis is to ensure that kubernetes is always pull the image even thought you have pulled before (this is to ensure you have always the latest).--this is to mark the end of the kubernetes commands and everything after is going to be the newman commands/arguments to run the postman script.
So, creating this deployment in the same namespace of your internal services, you can hit them and test the endpoints even though they are not external.
You should see something like this on your console:
This means that your script is running as expected in the cluster.
Thank you guys ! See you next time !
Chaos Engineering: Why Breaking Things Should be Practiced
Hello guys,
Last week I went to the WebSummit 2018 Conference in Lisbon and I managed to join some of the AWS talks. The talk that I am posting today is about chaos engineering, which specifically address the uncertainty of distributed systems at scale. The aim of this practice is to uncover the system weakness and build confidence in the system’s capability.
The harder it is to disrupt the steady state, the more confidence we have in the behavior of the system. If a weakness is uncovered, we now have a target for improvement before that behavior manifests in the system at large.
Today I am going to post the video on the exact moment that this talk starts.
https://player.twitch.tv/?autoplay=false&t=02h05m17s&video=v333130731
This talk is presented by AWS Technical Evangelist Adrian Hornsby.
You can find tools to help you with the tests in this repo:
https://github.com/dastergon/awesome-chaos-engineering#notable-tools
References:
https://principlesofchaos.org/
https://www.twitch.tv/videos/333130731
Amazing repo with content/links about the topic: https://github.com/dastergon/awesome-chaos-engineering
How do you help developers to test ?
Hello guys,
I have joined to some webinars from Test Masters Online, not sure if you heard about them, but this one really called my attention. The title looks a bit extreme, but you will see that is more about how testers and developers can work together to improve the quality of the team. The ideal is to have specialised QAs that can teach developers about automation, performance, security tests and so on. It is more about giving awareness about tests when developing.
The challenge nowadays is changing the developers mindset to contribute along with QAs with the automation tests and also getting support from the managers (which is something that I’ve always highlighted). If you want a team without a bottleneck and where everybody is max contributing for the quality and speed of the deliveries, then yes you need to think about a team sharing all the responsabilities and having a specilised person to guide and teach.
Basically you will see how Joel Montvelisky discusses the issues which prevents software developers to test, and what testers can do to change that.
Thank you !! See you in the next post 🙂
