enter image description here
hello i cant solve the task 6 idid all the steps but the problem is till can anyone help me ?
It is a known bug, i have already raised the ticket with Qwiklab support.
However, you can do the workaround like, BUILD_NUMBER is 1,2,3,4 based on jenkin job
You build image format should be like : gcr.io/${PROJECT}/valkyrie-app:dev.${IMAGE_TAG}
Go to project folder in GCloud CLI where Dockerfile is run this command
gcloud builds submit -t gcr.io/qwiklabs-gcp-00-<Number>/valkyrie-app:dev.5 .
Jenkin stage i used to print the build number and Image tag
stage('Print data') {
steps {
script {
sh "${IMAGE_TAG}"
sh "${env.BUILD_NUMBER}"
}
}
}
You can run this command to the application folder. it will submit the build to Google cloud build.
Once the image is pushed to the GCR you can update the image to deployment.yaml file and re-apply it simply.
Once POD are rollbacked, you can wait for 1-2 min and check the status.
Related
I am trying to follow example at How to deploy Flutter WebApp using Google Cloud Run and it says
Create a Dockerfile in the root folder; this file configures the
Docker image and containerizes the app. Copy the following content
into your Dockerfile
that I created as well as server.sh in server folder ,
When I run
gcloud builds submit — tag gcr.io/{PROJECT_ID}/{YOUR-IMAGE-NAME}:$tag .
C:\projects\myproject11>gcloud builds submit — tag gcr.io/myproject11/xyz:1.0
ERROR: (gcloud.builds.submit) unrecognized arguments:
tag
gcr.io/myproject11/xyz:1.0
To search the help text of gcloud commands, run:
gcloud help -- SEARCH_TERMS
C:\projects\myproject11>
Seems the error is due to long dash tag in the command you are trying to run. You need to add the -- before tag to indicate that it's a flag.you can check this document for examples
As mentioned here, looks like you are also facing the same issue as you following the example in medium .
The code block changes “dash dash tag” to “long dash tag” in Medium
code block formatting.It should be :
gcloud builds submit --tag gcr.io/$PROJECT_ID/pdf-service
When attempting to deploy to Cloud Run using the gcloud run deploy I am hitting the 10m Cloud Build timeout limit. gcloud run deploy is working well as long as the build step does not exceed 10m. When the build step exceeds 10m, the build fails with the "Timed out" status as shown in below screenshot. AFAIK there are no arguments to gcloud run deploy that can set the Cloud Build timeout limit. gcloud run deploy docs are here: https://cloud.google.com/sdk/gcloud/reference/run/deploy
I've attempted to increase the Cloud Build timeout limit using gcloud config set builds/timeout 20m and gcloud config set container/build_timeout 20m, but these settings are not reflected in the execution details of the cloud build process when using gcloud run deploy.
In the GUI, this is the setting I want to change:
Is it possible to increase the Cloud Build timeout limit using gcloud run deploy?
How about splitting the command into (more easily configured) constituents?
[I've not tried this]
Build the container image specifying the timeout
:
gcloud builds submit --source=.... --timeout=...
Then reference the image that results when you gcloud run deploy:
gcloud run deploy ... --image=...
I know this is answered and confirmed, but #DazWikin's solution was the harder way to solve this problem than #SimonKarman's solution.
For those who do not have the cloudbuild.yml file like myself, this solution still is a valid one, you just need to edit the one created by google itself. You can find it under builds > triggers > Desired Trigger (Edit)
Then when you open the editor you can apply the timeout. If you want other changes to the yaml file you can also checkout the schema here:
https://cloud.google.com/build/docs/build-config-file-schema#yaml
Note: I am using cloudrun and this worked for me and therefore I am not 100% if it works with all builds generated by google
Hope it will be helpful for someone else in future :)
If you're using a --source such as the cloudbuild.yaml you can add the following property to alter the timeout in seconds:
...
timeout: "1800s"
...
You can find this in the documentation
I am trying to include the Container Analyis API link in a Cloud Build pipeline.This is a beta component and with command line I need to install it first:
gcloud components install beta local-extract
then I can run the on demand container analyis (if the container is present locally):
gcloud beta artifacts docker images scan ubuntu:latest
My question is how I can use component like beta local-extract within Cloud Build ?
I tried to do a fist step and install the missing componentL
## Update components
- name: 'gcr.io/cloud-builders/gcloud'
args: ['components', 'install', 'beta', 'local-extract', '-q']
id: Update component
but as soon as I move to the next step the update is gone (since it is not in the container)
I also tried to install the component and then run the scan using (& or ;) but it is failling:
## Run vulnerability scan
- name: 'gcr.io/cloud-builders/gcloud'
args: ['components', 'install', 'beta', 'local-extract', '-q', ';', 'gcloud', 'beta', 'artifacts', 'docker', 'images', 'scan', 'ubuntu:latest', '--location=europe']
id: Run vulnaribility scan
and I get:
Already have image (with digest): gcr.io/cloud-builders/gcloud
ERROR: (gcloud.components.install) unrecognized arguments:
;
gcloud
beta
artifacts
docker
images
scan
ubuntu:latest
--location=europe (did you mean '--project'?)
To search the help text of gcloud commands, run:
gcloud help -- SEARCH_TERMS
so my question are:
how can I run "gcloud beta artifacts docker images scan ubuntu:latest" within Cloud Build ?
bonus: from the previous command how can I get the "scan" output value that I will need to pass as a parameter to my next step ? (I guess it should be something with --format)
You should try the cloud-sdk docker image:
https://github.com/GoogleCloudPlatform/cloud-sdk-docker
The Cloud Build team (implicitly?) recommends it:
https://github.com/GoogleCloudPlatform/cloud-builders/tree/master/gcloud
With the cloud-sdk-docker container you can change the entrypoint to bash pipe gcloud commands together. Here is an (ugly) example:
https://github.com/GoogleCloudPlatform/functions-framework-cpp/blob/d3a40821ff0c7716bfc5d2ca1037bcce4750f2d6/ci/build-examples.yaml#L419-L432
As to your bonus question. Yes, --format=value(the.name.of.the.field) is probably what you want. The trick is to know the name of the field. I usually start with --format=json on my development workstation to figure out the name.
The problem comes from Cloud Build. It cache some often used images and if you want to use a brand new feature in GCLOUD CLI the cache can be too old.
I performed a test tonight, the version is 326 in cache. the 328 has just been released. So, the cached version has 2 weeks old, maybe too old for your feature. It could be worse in your region!
The solution to fix this, is to explicitly request the latest version.
Go to this url gcr.io/cloud-builders/gcloud
Copy the latest version
Paste the full version name in the step of your Cloud Build pipeline.
The side effect is a longer build. Indeed, because this latest image isn't cached, it has to be downloaded in Cloud Build.
Currently, I found out a google cloud build happens during building a docker image time(not as I thought in that it would build my image and then execute my image to do all the building). That was in this post
quick start in google cloud build
soooo, I have a Dockerfile that is real simple now like so
FROM gcr.io/google.com/cloudsdktool/cloud-sdk:alpine
RUN mkdir -p ./monobuild
COPY . ./monobuild/
WORKDIR "/monobuild"
RUN ["/bin/bash", "./downloadAndExtract.sh"]
and I have a single downloadAndExtract that downloads any artifacts(zip files) from the last monobuild run that were built(only modified servers are built OR servers that dependend on changes in the last CI build are built like downstream libraries may be changed). This first line just lists urls of the zip files I need in a file...
curl "https://circleci.com/api/v1.1/project/butbucket/Twilio/orderly/latest/artifacts?circle-token=$token" | grep -o 'https://[^"]*zip' > artifacts.txt
while read url; do
echo "Downloading url=$url"
zipFile=${url/*\//}
projectName=${zipFile/.zip/}
echo "Zip filename=$zipFile"
echo "projectName=$projectName"
wget "$url?circle-token=$token"
mv "$zipFile?circle-token=$token" $zipFile
unzip $zipFile
rm $zipFile
cd $projectName
./deployGcloud.sh
cd ..
done <artifacts.txt
echo "DONE"
Of course, the deployGcloud script has these commands in it sooooo this means we are building docker images WHILE building the google cloud build docker image(which still seems funny to me)....
docker build . --tag gcr.io/twix/authservice
docker push gcr.io/twix/authservice
gcloud run deploy staging-admin --region us-west1 --image gcr.io/twix/authservice --platform managed
BOTH docker commands seem to be erroring out on this..
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
while the gcloud command seems to be very happy doing a deploy but just using a previous image we deployed at that location.
So, how to get around this error so my build will work and build N images and deploy them all to cloud run?
oh, I finally figured it out. Google has this weird thing in it's config.yaml files of use this docker image to run a curl command and then on next step use this OTHER dockerr image to run some other command and so on using 5 different images. This is all very confusing so instead, I realized I had to figure out how to create my ONE docker image and just run it as a command so I modify the above to have an ENTRYPOINT instead and then docker build and docker push my image into google. Then, I have a cloudbuild.yaml with a single step image command to run.
In this way, we can tweak our builds easily within our docker image that is just run. This is now way simpler than the complex model that google had setup as it becomes basic do your build in the container however you like and install whatever tools you need in the one docker image.
ie. beware the google quick starts which honestly IMHO are really overcomplicating it compared to circleCI and other systems. (of course, that is just an opinion and each to their own).
I ran the quick start
https://cloud.google.com/cloud-build/docs/quickstart-build
and in the section "View the build details", I don't see the output of the quickstart.sh file anywhere. Where is the logs from actually running the quickstart.sh file?
Without any output from quickstart.sh, I am unsure how to log what is going on in docker so I can fix broken builds that build in docker.
In this official tutorial, a docker container is built via Cloud Build, with only one executable bash script which is displaying the current date.
#!/bin/sh
echo "Hello, world! The time is $(date)."
Here is the Dockerfile :
FROM alpine
COPY quickstart.sh /
CMD ["/quickstart.sh"]
It means quickstart.sh is never executed during build phase but only at the execution step of container.
To see the output of script, you should run container (either locally on your computer, or via Cloud Shell) :
$ docker run gcr.io/[PROJECT-ID]/quickstart-image:latest
Hello, world! The time is Sat Jun 13 05:10:41 UTC 2020.
If you want to execute a script during build phase of container, you should use RUN command.
For example, let's create a second executable script called build.sh in the same directory:
#!/bin/sh
echo "Hello, build at $(date)."
Then, add it on Dockerfile file description :
FROM alpine
COPY quickstart.sh /
COPY build.sh /
RUN /build.sh
CMD ["/quickstart.sh"]
Now, we can build a new version of container image :
gcloud builds submit --tag gcr.io/[PROJECT-ID]/quickstart-image
This time, output of build.sh could be seen in the details output log in Cloud Build console:
Of course, here it's just a simple example to give you a quick answer. You may check all other possible options to write a correct and clean Dockerfile. But it's not really linked with Cloud Build.