ERROR: (gcloud.auth.activate-service-account) The .json key file is not in a valid format -- via impersonate-service-account - bash

Is it possible to use short-lived credentials, with docker-compose, to run a bash scripted gcloud command?
Related posts that I attempted to use but they are 5+ years old and I've been led to believe that the gcloud auth command has changed during this time:
ERROR: (gcloud.auth.activate-service-account) Failed to activate the given service account. Please ensure provided key file is valid
gcloud auth activate-service-account [ERROR] Please ensure provided key file is valid
Setup
there is a lot going on but I've attempted to abbreviate to the relevant parts
Makefile
auth: ## commands for short lived auth
#gcloud config set project ${GCP_PROJECT}
#gcloud auth application-default login --impersonate-service-account="inst-dataflow-svc#${GCP_PROJECT}.iam.gserviceaccount.com"
#gcloud auth configure-docker $(REGION)-docker.pkg.dev
gcloud-flex-build: ## build & push base docker image
docker-compose build gcloud-build-flex-local
docker-compose run gcloud-build-flex-local
docker-compose.yaml
version: '3.4'
services:
gcloud-build-flex-local:
build:
dockerfile: docker/gcloud-build-flex-template.dockerfile
context: .
image: us-central1-docker.pkg.dev/gcp-project/dataflow-docker-registry/local-build/pubsub-to-gbq-build-flex-template
volumes:
- type: bind
source: ${HOME}/.config/gcloud/
target: /tmp
docker/gcloud-build-flex-template.dockerfile
FROM gcr.io/google.com/cloudsdktool/cloud-sdk:408.0.1
COPY docker/scripts/gcloud-build-flex-template.sh /app/gcloud-build-flex-template.sh
COPY dataflow/pubsub-to-gbq/pubsub-to-gbq-metadata /app/pubsub-to-gbq-metadata
WORKDIR /app
ENTRYPOINT "/app/gcloud-build-flex-template.sh"
/app/gcloud-build-flex-template.sh
#!/bin/bash
set -euo pipefail
SERVICE_ACCOUNT_EMAIL=inst-dataflow-svc#gcp-project.iam.gserviceaccount.com
GCP_PROJECT=gcp-project
export GOOGLE_APPLICATION_CREDENTIALS=/tmp/application_default_credentials.json
# debugging
echo $GOOGLE_APPLICATION_CREDENTIALS
ls -lah /tmp/
cat $GOOGLE_APPLICATION_CREDENTIALS
gcloud auth activate-service-account $SERVICE_ACCOUNT_EMAIL --project=$GCP_PROJECT --key-file=$GOOGLE_APPLICATION_CREDENTIALS
Execution
make auth
make gcloud-flex-build
Error
ERROR: (gcloud.auth.activate-service-account) The .json key file is not in a valid format.
make: *** [gcloud-flex-build] Error 1
stdout (abbreviated)
docker-compose build gcloud-build-flex-local
[+] Building 0.4s (9/9) FINISHED
...
docker-compose run gcloud-build-flex-local
drwxr-xr-x 17 root root 544 Dec 30 10:36 .
drwxr-xr-x 1 root root 4.0K Dec 30 10:40 ..
-rw------- 1 root root 591 Dec 30 10:36 application_default_credentials.json
{
"delegates": [],
"service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/inst-dataflow-svc#gcp-project.iam.gserviceaccount.com:generateAccessToken",
"source_credentials": {
"client_id": "alphanumeric string .apps.googleusercontent.com",
"client_secret": "alphanumeric string",
"refresh_token": "alphanumeric string",
"type": "authorized_user"
},
"type": "impersonated_service_account"
}
I can make it work via docker run by spoofing the credentials to include only the "source_credentials" object, passed in as a volume, but this same trick doesn't seem to work with docker-compose running a script inside a container...

There is a similar type of configuration mentioned in this document. This involves three major steps:
Create short-lived credentials for your service account and download
your service account keys.
Create the configuration files for making your docker environment up. Use
the above cred files for granting required permissions.
Once you have all the configuration files in place use your docker-compose
commands for making your environment up.
Follow this documentation for more details.

Related

Spring Boot app in Docker container not starting in Cloud Run after building successfully - cannot access jarfile

I've set up continuous deployment to Cloud Run from GitHub for my Spring Boot project, and while it's successfully building in Cloud Build, when I go over to Cloud Run, I get the following error under Creating Revision:
The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable.
When I go over to the Logs, I see the following errors:
2022-09-23 09:42:47.881 BST
Error: Unable to access jarfile /app/target/educity-manager-0.0.1-SNAPSHOT.jar
{
insertId: "632d7187000d739d29eb84ad"
labels: {5}
logName: "projects/educity-manager/logs/run.googleapis.com%2Fstderr"
receiveTimestamp: "2022-09-23T08:42:47.883252595Z"
resource: {2}
textPayload: "Error: Unable to access jarfile /app/target/educity-manager-0.0.1-SNAPSHOT.jar"
timestamp: "2022-09-23T08:42:47.881565Z"
}
2022-09-23 09:43:48.800 BST
run.googleapis.com
…ager/revisions/educity-manager-00011-fod
Ready condition status changed to False for Revision educity-manager-00011-fod with message: Deploying Revision.
{
insertId: "w6ptr6d20ve"
logName: "projects/educity-manager/logs/cloudaudit.googleapis.com%2Fsystem_event"
protoPayload: {
#type: "type.googleapis.com/google.cloud.audit.AuditLog"
resourceName: "namespaces/educity-manager/revisions/educity-manager-00011-fod"
response: {6}
serviceName: "run.googleapis.com"
status: {2}}
receiveTimestamp: "2022-09-23T08:43:49.631015104Z"
resource: {2}
severity: "ERROR"
timestamp: "2022-09-23T08:43:48.800371Z"
}
Dockerfile is as follows (and looking at the build log all of the commands in it completed successfully):
FROM openjdk:17-jdk-alpine
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring
COPY . /app
ENTRYPOINT [ "java","-jar","/app/target/educity-manager-0.0.1-SNAPSHOT.jar" ]
I've read that Cloud Run defaults to exposing Port 8080, but just to be on the safe side I've put server.port=${PORT:8080} in my application.properties file (but it seems to make no difference one way or the other).
I have run into similar issues in the past. Usually, I am able to resolve this issue by:
specifying the port in the application itself (as you indicated in your post), and
exposing the required port in my dockerfile eg. EXPOSE 8080
Oh my good god I have done it. After two full days of digging, I realised that because I was doing it through github, my .gitignore file was excluding the /target folder containing the jar file, so Cloud Build never got the jar file mentioned in the Dockerfile.
I am going to have a cry and then go to the pub.

Failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB) in quic golang appengine

I am using a google cloud app engine to deploy my quic-go server. But getting the error:
failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB).
I am using app.yaml file to build a docker file which is as follows:
FROM golang:1.18.3
RUN mkdir /app
ADD . /app
WORKDIR /app
RUN apt-get update && apt-get install -y ffmpeg
CMD sudo --sysctl net.core.rmem_default=15000000
CMD sudo --sysctl net.core.rmem_max=15000000
RUN go build -x server.go
ENV GCS_BUCKETNAME xyz
ENV AI_CLIENT_SSL_CERT /path to cert
ENV AI_CLIENT_SSL_KEY /path to key
ENV GCP_BUCKET_SERVICE_ACCOUNT_CREDS /path to google cloud service account credential
CMD [ "./server" ]
This is my app.yaml
runtime: custom
env: flex
env_variables:
GCS_BUCKETNAME : "xyz"
AI_CLIENT_SSL_CERT : "./path to cert"
AI_CLIENT_SSL_KEY : "./path to key"
GCP_BUCKET_SERVICE_ACCOUNT_CREDS : "./path to google cloud credential.json file"
service: streaming-app
automatic_scaling:
min_num_instances: 1
max_num_instances: 20
cpu_utilization:
target_utilization: 0.85
target_concurrent_requests: 100
Any sort of help will be appreciated.
Since sysctl is an OS-level config that doesn't fit in line with App Engine's principle use case. App Engine does not currently have any way of configuring the underlying sysctl config files. I believe that Google Kubernetes engine may be a better use case for running that server, as App Engine environments have a limited set of configurable settings.
can you tell me the scenarios when this file is not present in the kernel?
I’m not sure about the scenarios as I have least experience with kernel. For me it seems a different question rather than original post. you can raise a new StackOverflow question regarding this.

ebextensions not working in AWS Elasticbeanstalk

When deploying in elasticbeanstalk, I am trying to execute a script through an ebextension file.
The log says that the script was executed normally, but it doesn't seem to be applied.
The exact content of the script is a script that sends logs from laravel to cloudwatch through cloudwatch agent.
Below is the contents of the script and the log that the script was executed normally.
ebextention_file.config
files:
"/etc/awslogs/config/laravel_log.conf" :
mode: "060606"
owner: root
group: root
content: |
[/var/app/current/storage/logs/laravel*]
datetime_format = %Y-%m-%d %H:%M:%S
log_group_name = `{"Fn::Join":["/", ["/aws/elasticbeanstalk", { "Ref":"AWSEBEnvironmentName" }, "var/app/current/storage/logs/laravel.log"]]}`
log_stream_name = {instance_id}
file = /var/app/current/storage/logs/laravel*
multi_line_start_pattern = {datetime_format}
commands:
"01":
command: chkconfig awslogs on
"02":
command: service awslogs restart
cfn-init.log:
2020-09-17 03:43:19,921 [INFO] Command 01 succeeded
2020-09-17 03:43:22,056 [INFO] Command 02 succeeded
It is not possible after deployment,
so if i directly connect to each instance with ssh and execute 01 command and 02 command, logs are normally entered in cloudwatch.
I don't know what this is
Deployment policy: rolling with additional batch
Rolling update type: rolling based on Health
What are some more things I should check

How do I properly create buildspec.yml file for Laravel Application using AWS CodePipeline

I am using AWS CodePipeline for the first time and trying to figure out how to properly create my buildspec.yml file for my Laravel application. There are few resources on the internet.
I have the following in my buildspec.yml file currently:
version: 0.2
phases:
install:
commands:
- curl -s https://getcomposer.org/installer | php
- mv composer.phar /usr/local/bin/composer
- php --version
build:
commands:
- echo Build started on `date`
- echo Installing composer deps
- composer install
- cp extra/.env ./
- php artisan cache:clear
post_build:
commands:
- echo Build completed on `date`
artifacts:
type: zip
files:
- '**/*'
name: clyde-$(date +%Y-%m-%d)
The CodeBuild is successful and this does deploy to Elastic Beanstalk. I did change the configuration in Elastic Beanstalk so the root is /public (for Laravel). However, when I go to the URL, the first line of code run presents an error like below:
View [inc\navbar] not found. (View: /var/app/current/resources/views/layouts/app.blade.php)
This leads me to believe something is not built properly.
To make it work, it will need to use a complete Pipeline: CodeCommit-->CodeBuild-->CodeDeploy
Inside your Artifact bucket there will be two objects generated in the process:
s3://codepipeline-us-east-1-<001122334455>/SourceArtif/
s3://codepipeline-us-east-1-<001122334455>/BuildArtif/
The first one is obtained in the initial phase of the pipeline from CodeCommit.
The second one is created by CodeBuild. The resultant zip file will be exactly the same as that one from CodeCommit. So it seems, the CodeBuild is only testing but not saving the Artifact with results from the instructions specified in buildspec.yml.
The third phase, CodeDeploy will obtain the code from the Artifact and it will need to Build again via scripts referred by appspec.yml.
version: 0.0
os: linux
files:
- source: /
destination: /web/project/html
hooks:
BeforeInstall:
- location: scripts/install_dependencies.sh
timeout: 300
runas: root
AfterInstall:
- location: scripts/build_again.sh
timeout: 600
runas: user
ApplicationStart:
- location: scripts/start_application.sh
timeout: 300
runas: root
The build_again.sh file will need to include same commands you are using in buildspec.yml (build section), then your Laravel project should be working.

Codedeploy-agent error when run in amazon linux instance

When I create a new deploy in AWSCodeDeploy with GitHub I receive this fail message:
Error CodeScriptFailed
Script Namescripts/stop_server.sh
MessageScript at specified location: scripts/stop_server.sh run as user ubuntu failed with exit code 1
Log TailLifecycleEvent - ApplicationStop
Script - scripts/stop_server.sh
[stderr]su: user ubuntu does not exist
But, my instance is an Amazon Linux Instance and don't have a ubuntu user, anybody know anything about this?
The script that a try to run is:
# scripts/stop_server.sh
#!/bin/bash
forever stop .
My appspec.yml file:
version: 0.0
os: linux
files:
- source: /
destination: /home/ec2-user
hooks:
AfterInstall:
- location: scripts/install_dependencies.sh
timeout: 5
runas: root
ApplicationStart:
- location: scripts/start_server.sh
timeout: 5
runas: root
ApplicationStop:
- location: scripts/stop_server.sh
timeout: 5
runas: root
Codedeploy-agent version agent_version: OFFICIAL_1.0-1.1095_rpm
Application stop usually refers to appspec.yml in previous successful deployment archive. Either empty /opt/codedeploy-agent/deployment-archive/deployment-instructions/ or you may use BeforeInstall hook to execute stop script.
The code deploy create temporary application inside /opt/code-deploy/.... path. If the deployment fails normally it starts from the temporary directory next time. If you want to get rid of the error pointing by deployment, you should check the particular script file in the temporary directory and edit it.

Resources