How to troubleshoot docker unauthorized 401 error

aamdevsecops — Sun, 08 Jan 2023 15:19:04 +0000

This is an example from a public repository that was causing an issue.

https://github.com/MilenkoMarkovic/intens-api-2022

I created a hub.docker.com account which comes with one free repository.

Then proceed with the steps below:

Here is my test Dockerfile:

FROM openjdk:8-jdk-alpine

WORKDIR /opt/app

COPY target/aamdevsecops-1.1.1-SNAPSHOT.jar /opt/app/

CMD ["java","-jar","aamdevsecops-1.1.1-SNAPSHOT.jar"]

Of course, i changed the <name>, <version> and <artifactoryId> in pom.xml file to match my Dockerfile.

First, i built the package locally by issuing this command on the intense-api git project folder:

mvn package

Then, I built the docker image out of it:

docker build -t aamdevsecops:1.1.1 .

then logged in to docker with my hub.docker.com credentials.

docker login # you will be prompted for credentials of hub.docker.com account

tagged the image: docker tag aamdevsecops/devops-bootcamp:latest

then: docker push aamdevsecops/devops-bootcamp:1.1.1

Finally, I did:

docker run --name aamdevsecops -p 8090:8090 aamdevsecops/devops-bootcamp:latest

And here's the result:

Jan 6 '23 Comments: 13 Answers: 2

My Dockerfile

FROM openjdk:8-jdk-alpine
WORKDIR /opt/app

COPY target/pichk-0.0.1-SNAPSHOT.jar /opt/app/

CMD ["java","-jar","pichk-0.0.1-SNAPSHOT.jar"]
EXPOSE 8090

When I run image

docker run -p 8090:8090 pichk:001

I got error

docker: you are not authorized to perform this operation: server returned 401.

I am adding target permissions line

drwxrwxr-x   9 miki miki  4096 Jan  4

…

Open Full Question

How to prevent destroy an instance after an update

aamdevsecops — Tue, 27 Dec 2022 17:48:33 +0000

While stumbling upon stackoverflow to crawl some posts about GCP and Terraform as part of my learning curve, I came across this particular issue:

How can I update an instance as part of the Infrastructure as Code after creation.

After hours of research, manual errors and trials, it turned out that the issue was on plain sight...to quote Benoît Blanc.¹. Being enthusiastic about my findings, I wanted to answer.

So, it turns out that:

"Instance Templates cannot be updated after creation with the Google Cloud Platform API. In order to update an Instance Template, Terraform will destroy the existing resource and create a replacement. In order to effectively use an Instance Template resource with an Instance Group Manager resource, it's recommended to specify create_before_destroy in a lifecycle block. Either omit the Instance Template name attribute, or specify a partial name with name_prefix"
².

Concretly, three options:

1. Use create before destroy lifecycle:

Example:

   resource "google_compute_region_instance_group_manager" "my_service_mig" {
      version {
        instance_template = google_compute_instance_template.my_service_template.id
        name              = "primary"
      }

+ lifecycle {
+   create_before_destroy = true
+ }
}

2. Use prevent_destroy

resource "google_compute_region_instance_group_manager" "my_service_mig" {
      version {
        instance_template = google_compute_instance_template.my_service_template.id
        name              = "primary"
      }

+ lifecycle {
+   prevent_destroy = true
+ }
}

3. Quick and dirty

terraform plan | grep <resource> | grep id 
terraform state rm <resource>
terraform apply
terraform import <resource> <ID>

My original answer, here:

Dec 23 '22 Comments: 1 Answers: 1

I have a service deployed on GCP compute engine. It consists of a compute engine instance template, instance group, instance group manager, and load balancer + associated forwarding rules etc.

We're forced into using compute engine rather than Cloud Run or some other serverless offering due to the need for…