Sanity tests by name suggests the case that validate if the application is sane. For example in context of sign up of a website, you may have the following tests as sanity:

• Sign up option is available on login page.
• Clicking "Sign up" redirects to proper , sign up form.
• Clicking Sign in does not re-direct to "Sign up" form.
• Submitting "Sign up" form goes successful, with out crash.
• User signed up, is able to login.

The above are more then enough for a sanity test. But for detailed testing you may include following tests in addition to the above one.

• Signing up again, with same user id, is not allowed.
• injection is restricted.
• Once signed up, user is allowed to sign in from multiple devices / browsers, without need to sign up again.
• Cancelling mid-way sign up(half-filled form), is allowed.
• Only the mandatory fields in form(if blank) should block the sign up.
• Blank form sign up should not be allowed.

I resolved the problem by publishing the terraform files from the Build pipeline:

- publish: $(Build.SourcesDirectory)/terraform
  artifact: Terraform

I also realised that I could run terraform validate and other static analysis in the Build pipeline, and failing the build if this does not pass. So the Deploy pipeline has less validation to do and is just concerned with deployment.

I have solved the coredns problem by running

sudo sed -i '$ s/$/ cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1/' /boot/cmdline.txt

in my raspbian.

I'd like to connect several services with a reverse proxy. But the services can't communicate with each others.

I'm using a compose file for each service.

I'm trying to use the same external bridge (icc=false).

After that, I don't understand how to allow the different communication with the reverse proxy. I've tried links and external_links but it doesn't work. Then, I have read that link will be deprecated...

Sorry for my english, I'm not a native speaker. Thanks, have a good day.

#Example of Test1 compose file:
version: '3'
services:
  app:
    image: nicolaka/netshoot:latest
    tty: true
    restart: always
    networks:
      app-net:
    external_links:
      - test2-app-1
networks:

app-net:

external:

name: bridge_icc_false #created with com.docker.network.bridge.enable_icc=false

So I found some answers over time, posting them here in case it helps anyone.

• The Userdata never ran, I can't find see any of the above echo statements in the logs /var/log/cloud-init.log. When I SSH into the instance I can't find any of these files. How do I debug this better?

  ANS: There was an error in my Userdata, I SSHed into the instance and ran the script manually to debug and fix all issues.

• On code update, Cloudformation stack is updated, this does not run Userdata(?) (I know it only runs when an instance is first created, but I would like some confirmation that Cloudformation update does not trigger this

  ANS: Cloudformation terminates the old instance and spins up a new one on each deploy, this causes the Userdata to be run each time.

• Is this an ideal flow? Are there any improvements I can make here, considering I'm not an expert, but willing to spend some time learning where required.

  ANS: It was not. The primary reason I was doing this was to fire async requests from one lambda to another, without waiting for the results. This is not possible, as the lambda will not wait for any requests that you do not await meaning you still have to wait for those operations. I tried asynchronous invocation but it still did not work (For those interested I posted a question about it https://stackoverflow.com/questions/72493614/serverless-express-lambda-async-invoke-not-working ). So I switched to using SNS to publish messages from one lambda to trigger another, achieving my requirement for fire and forget requests.

I have no experience with AWS and I would like to know what the best approach is when it comes to embedding an environment built using Docker Compose (a simple application with two services, API and Redis), I came across such possibilities at the moment:

• making an EC2 instance, connecting via SSH, configuring the environment and manually building and running the environment (can you somehow automate it?)
• making an ECS, uploading a docker image to the ECR, setting a cluster and a ribbon to start building the environment based on the image from the ECR
• using Elastic Beanstalk, making applications using Docker and managing from the CLI level (eb init, create, deploy) They are different? (additionally connecting CodePipeline and maybe GH Actions)

What approach in such situations is practiced in your companies and what should you be most careful about?

The EC2 metadata endpoint has been updated to handle this situation but your current configuration may be preventing it. Have a read here for more: https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-eks-supports-ec2-instance-metadata-service-v2/

Now, newly launched and any updated EKS managed node groups will be configured with a metadata token response hop limit set to 2. For self-managed nodes, CloudFormation templates and eksctl have been updated to launch nodes by default with a hop limit of 2.

Given that you have the hop limit updated, you can use the IMDSv2 endpoint by first getting a token, and passing that through with your request

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/

For availability zone:

curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/placement/availability-zone/

We just moved to kubernetes, but the engineer that helped launch it is on paternity leave before we had hoped (never trust a baby not to be eager!).

Now we're trying to do maintenance tasks and one off work and having nodes get killed in the middle of things.

I've looked at using kubernetes jobs for this, but that's overkill. We don't want to write manifest files for everything.

We just need long lived shell access to do this and that.

What's the pattern for this so your maintenance task doesn't get killed?

Maybe you can use a Webhook to read information from the repository. So that way you can access dynamic information such as the repository URL where to look the code, and even create or loaunch specifics Jobs for each Repo.

https://plugins.jenkins.io/generic-webhook-trigger/ Support passing parameters.

I guess it's not the best solution, because it involves configuring each Git repository, but it's quite powerful and dynamic.

I hope you can find a good solution

I have a docker container where I run a few commands as a root user each time it is created from an image. Is it possible to automate running these commands as a root administrator user each time my container is created?

# apt-get update
apt-get upgrade
apt-get install -y vim

I added routes in each of the subnets on both requestor and receiver side and it worked.