kubectl set image throws error: the server doesn't have a resource type deployment" - jenkins

Environment: Win 10 home, gcloud sdk v240.0 kubectl added as a gcloud sdk component, Jenkins 2.169
I am running a Jenkins pipeline in which I call a windows batch file as a post-build action.
In that batch file, I am running:
kubectl set image deployment/py-gmicro py-gmicro=%IMAGE_NAME%
I get this
error: the server doesn't have a resource type deployment
However, if I run the batch file directly from the command prompt, it works fine. Looks like it has an issue only if I run it from Jenkins.
Looked at a similar thread on stackoverflow, however that user was using bitbucket (instead of Jenkins).
Also, there was no certified answer on that thread. I cannot continue on that thread since I am not allowed to comment (50 reputation required)

Just was answered on this thread
I've had this error fixed by explicitly setting the namespace as an argument, e.g.:
kubectl set image -n foonamespace deployment/ms-userservice.....
Refrence:
https://www.mankier.com/1/kubectl-set-image#--namespace

Related

Puppet Code Manager setup issue with Bitbucket

I have just installed puppet server enterprise and successfully added a few nodes and got some custom modules running also. I am now wanting to move to Code Manager before we get too deep in it.
I have followed the instructions for creating an empty Bitbucket repo here and initializing it with one single file environment.conf on a production branch as described in that link.
I have then followed the steps here to configure Code Manager but when I get to Test the control repository section to test the connection with puppet-code deploy --dry-run I get the following error:
--dry-run implies --all.
--dry-run implies --wait.
Dry-run deploying all environments.
2021/12/21 20:21:12 ERROR - [POST /deploys][500] Errors while collecting a list of environments to deploy (exit code: 1).
"/opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/gems/rugged-0.27.7/lib/rugged/repository.rb:258: warning: Using the last argument as keyword parameters is deprecated\nERROR\t -\u003e Unable to determine current branches for Git source 'puppet' (/etc/puppetlabs/code-staging/environments)\nOriginal exception:\nFailed to authenticate SSH session: Unable to send userauth-publickey request at /opt/puppetlabs/server/data/code-manager/git/git#git.company.com-1234-in-puppet-control-repo.git\n"
I have added the puppet server's SSH pub key to the bitbucket repo's access tokens.
There are a few things in that error message im not fully understanding.
Unable to determine current branches for Git source 'puppet' - What is meant by source 'puppet' - my repo is called puppet-control-repo...?
Failed to authenticate SSH session: Unable to send userauth-publickey request - My puppet master's SSH keys are in the token list for that repo so confused here also.
Any guidance would be appreciated.
UPDATE (13-01-2022):
I can successfully clone on puppet server using command
git clone ssh://git#git.example.com:1234/project/puppet-control-repo.git --config core.sshCommand="ssh -i /etc/puppetlabs/puppetserver/ssh/id-control_repo.rsa"
Note sure why puppet is still returning:
Failed to authenticate SSH session: Unable to send userauth-publickey request
I don't know if you saw the instructions here https://puppet.com/docs/pe/2021.4/control_repo.html#managing_environments_with_a_control_repository but you can run
puppet infrastructure configure
which makes sure the files have right permissions.
I would also test attempting a clone with keys works outside of code deploy
git clone -i /etc/puppetlabs/puppetserver/ssh/id-control_repo.rsa your_gir_url
If this works it may be worth being aware of an issue we experienced on github https://puppet.com/blog/how-githubs-protocol-changes-impact-your-puppet-code-deployments/ which depending on bitbuckets approach to protocal may be having a similar affect.
We are updating docs to recommend the usage of more secure keys ed25519 creating as per the article.
if a manual clone doesnt work it suggests bitbucket doesn't have your public key correctly
Also a more complete debugging command is
runuser -u pe-puppet -- /opt/puppetlabs/puppet/bin/r10k -c /opt/puppetlabs/server/data/code-manager/r10k.yaml deploy environment production --puppetfile --verbose debug2
FOLLOWUP
On investigation we found https://support.puppet.com/hc/en-us/articles/227829007 which showed ssh:// was required at the start of r10k_remote making an example command of ssh://git#bitbucket.org:davidsandilands/control-repo.git
I have requested updates to https://support.puppet.com/hc/en-us/articles/227829007 to highlight this is not a version confined issue and asked for the puppet code manager configuration docs to be updated to reflect this may be required.
I see that you have a .pub file in the ssh directory. I believe it's expecting a private key there.
Also do you have the master class set up to point to your repo inside of Puppet Enterprise web ui?
You'll want to set the following parameters on that class.
code_manager_auto_configure = true
r10k_private_key = $PRIVATE_KEY_IN_SSH_FOLDER_ABSOLUTE_PATH
r10k_remote = Your git URL
The PE Master can be found in Node Groups on the PE Web UI Node Groups -> PE Infrastructure -> PE Master
Thanks to #david-sandilands for helping me resolve this and guiding me to this article via the puppet community slack. Top guy!
EDIT 1:
The solution was documented here: https://support.puppet.com/hc/en-us/articles/227829007-Fix-your-Bitbucket-Stash-Code-Manager-configuration-in-Puppet-Enterprise-2015-3-to-2017-2
However the documentation was out of date as it affected version 2021.4 also.
In short:
r10k_remote = "ssh://git#git.company.com:1234/project/control-repo.git"
Not
r10k_remote = "git#git.company.com:1234/project/control-repo.git"
When working with Bitbucket Server.
EDIT 2:
Puppet have since updated their documentation:
https://puppet.com/docs/pe/2021.5/code_mgr_config.html#code_mgr_enable

Trying to install logging on google cloud run but it's failing

I am trying to follow these instructions to log correctly from java to logback to cloudrun...
https://cloud.google.com/logging/docs/setup/java
If I used jdk8, I get alpn missing jetty issues so I moved to a Docker image openjdk:10-jre-slim
and my DockerFile is simple
FROM openjdk:10-jre-slim
RUN mkdir -p ./webpieces
COPY . ./webpieces/
COPY config/logback.cloudrun.xml ./webpieces/config/logback.xml
WORKDIR "/webpieces"
ENTRYPOINT ./bin/customerportal -http.port=:$PORT -hibernate.persistenceunit=cloud-production
AND the only difference is I switched the image from openjdk:8-jdk-alpine which worked fine!!!
When I deploy to google cloud I get this error...
Deploying container to Cloud Run service [staging-customerportal] in project [orderly-gcp] region [us-west1]
⠏ Deploying... Cloud Run error: Invalid argument error. Invalid ENTRYPOINT. [name: "gcr.io/orderly-gcp/customerportal2#sha256:6c1c2e7531684d8f50a3120f1de60cade841ab1d9069b
704ee3fd8499c5b7779"
error: "Invalid command \"/bin/sh\": file not found"
].
X Deploying... Cloud Run error: Invalid argument error. Invalid ENTRYPOINT. [name: "gcr.io/orderly-gcp/customerportal2#sha256:6c1c2e7531684d8f50a3120f1de60cade841ab1d9069b
704ee3fd8499c5b7779"
error: "Invalid command \"/bin/sh\": file not found"
].
. Routing traffic...
Deployment failed
ERROR: (gcloud.run.deploy) Cloud Run error: Invalid argument error. Invalid ENTRYPOINT. [name: "gcr.io/orderly-gcp/customerportal2#sha256:6c1c2e7531684d8f50a3120f1de60cade841ab1d9069b704ee3fd8499c5b7779"
error: "Invalid command \"/bin/sh\": file not found"
].
However, when I run locally to test, I get this error on project ID being required so it seems it is working. SIDE QUESTION: How to simulate this project ID so I can still run locally?
03:10:08,650 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CLOUD]
03:10:09,868 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter#14:13 - RuntimeException in Action for tag [appender] java.lang.IllegalArgumentException: A project ID is required for this service but could not be determined from the builder or the environment. Please set a project ID using the builder.
at java.lang.IllegalArgumentException: A project ID is required for this service but could not be determined from the builder or the environment. Please set a project ID using the builder.
at at com.google.common.base.Preconditions.checkArgument(Preconditions.java:142)
at at com.google.cloud.ServiceOptions.<init>(ServiceOptions.java:285)
at at com.google.cloud.logging.LoggingOptions.<init>(LoggingOptions.java:98)
at at com.google.cloud.logging.LoggingOptions$Builder.build(LoggingOptions.java:92)
at at com.google.cloud.logging.LoggingOptions.getDefaultInstance(LoggingOptions.java:52)
at at com.google.cloud.logging.logback.LoggingAppender.getLoggingOptions(LoggingAppender.java:246)
at at com.google.cloud.logging.logback.LoggingAppender.getProjectId(LoggingAppender.java:209)
at at com.google.cloud.logging.logback.LoggingAppender.start(LoggingAppender.java:194)
at at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90)
at at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309)
at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193)
at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179)
at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110)
The Java 10 version is EOL, and the official images has been removed. More detail here
Prefer a Java 11 version.
Anyway, when you use version, some are optimized and does not install bash by default (for reducing their size) and you have to install it by yourselves.
For a local run, I don't recommend to use a JSON key file (in general, don't use JSON key file, except for automated system out of GCP) due to security constraint, key rotation, secure storage,...
For setting the project, simply perform this command gcloud config set project MY_PROJECT. You don't need credential for this.
Since your current question is how to simulate the project ID for local testing:
You should download service account key file from https://console.cloud.google.com/iam-admin/serviceaccounts/project?project=MY_PROJECT, make it accessible inside docker container and activate it via
gcloud auth activate-service-account --key-file my_service_account.json
gcloud config set project MY_PROJECT
This problem may be due to the fact that alpine doesn't have bash:
"/bin/sh" therefore a solution could be to remove the dependency on bash itself by not using bash or by using exec instead of bash.
in my case I solved the problem by using a more complete base image, instead of alpine for instance.
HTH

Can't attach CircleCI Workspace from Windows to Linux due to "Cannot change ownership to uid 3434"

I am using CircleCI's persistent workspace feature to run jobs with the same build folder between Linux and Windows executor types. I was able to go from Linux to Windows but when I went from Windows to Linux I got this error when CircleCI attempted to attach the workspace.
Applying workspace layers:
9ba3eddc-3658-43c2-858b-aea39250af3e
25c476af-8804-4125-b979-05a62a9ac204
Error applying workspace layer for job 25c476af-8804-4125-b979-05a62a9ac204: Error extracting tarball /tmp/workspace-layer-25c476af-8804-4125-b979-05a62a9ac204854634413 : tar: project/.circleci/config.yml: Cannot change ownership to uid 3434, gid 197121: Invalid argument
Looking at the error it's clear that the UIDs are not existing on the system. I attempted to run commands to create the same UID/GID it was erroring on but I still got an unable to change owner issue.
I was expecting CircleCI to move the files and ignore the user: group part when it was extracted as you can't guarantee the UID/GID exists.
I opened a support ticket but hoping for a faster solution to this issue.
I found a solution to this issue and it's forcing CircleCI to use TAR_OPTIONS environment variable to force the options to ignore the owner/group.
Here is what I added to my jobs steps that attach the workspace when the previous job run was Window.
build-app:
build:
docker:
- image: Dockerhub.com/myrepo/myimage:1.0.0
environment:
TAR_OPTIONS: --no-same-owner
using TAR_OPTIONS environment to inject the option --no-same-owner allowed CircleCI to extract the tarball without issue.

Build Agent is Offline

I m using TFS 2015, I saw that my build Agent is Offline :
I launch the VsoWorker.exe to see the logs and understand the error, Here is what I get but I found nothing from the internet : Any Idea please ?
16:07:57.649004 Sending trace output to log files: C:\Users\Administrator\Downloads\agent\_diag
16:07:57.649004 vsoWorker.exe was run with the following command line:
"C:\Users\Administrator\Downloads\agent\Agent\Worker\VsoWorker.exe"
16:07:57.649004 VsoWorker.Main(): Create AgentLogger
16:07:57.649980 VsoWorker.Main(): Parse command line
16:07:57.655848 ---------------------------------------------------------------------------
16:07:57.657635 System.Exception: The /name command line option is required and must have a value.
16:07:57.657635 at VsoWorker.CommandLine.ValidateCommandLine()
16:07:57.657635 at VsoWorker.CommandLine..ctor(String[] args)
16:07:57.657635 at VsoWorker.Program.Main(String[] args)
16:07:57.657635 at VsoWorker.CommandLine.ValidateCommandLine()
16:07:57.657635 at VsoWorker.CommandLine..ctor(String[] args)
16:07:57.657635 at VsoWorker.Program.Main(String[] args)
16:07:57.657635 ---------------------------------------------------------------------------
16:07:57.658878 BaseLogger.Dispose()
When you install the Build Agent you are instructed to make a C:\Agents folder:
If you have not first configured the Build Agent, open Powershell and run this command:
PS C:\agent> .\config.cmd
In the config setup there is an option to run the Build Agent as a Window Service. This way you don't need to start it each time the machine reboots.
If you've found the BuildAgent has been installed but is offline, it's probably not been configured to run as a Service
and you will need execute this command to run the Build Agent or just double click the file:
PS C:\agent> .\run.cmd
This should bring the Build Agent online.
Note: The 1st time I tried this and it worked. The second time it didn't and I ran the C:\agent\bin\Agent.Listener.exe instead. I tried a 3rd time running the run.cmd and this time I waited a minute or 2 and it worked:
Note: You're better off making the agent run as a Service, this way you only need to run the config.cmd once and never need to run the run.cmd.
Make sure you deploy the Windows build agent by exactly following this article.
Make sure the account that the agent is run under is in the "Agent Pool Service Account" role.
Try to change a domain account which is a member of the Build Agent Service Accounts group and belongs to "Agent Pool Service Account" role, to see whether the agent would work or not.
Don't run the VsoWorker.exe application directly. Use the RunAgent.cmd file.

Jenkins accessing Window Server

I have the following problem: I have an ANT-task in Jenkins-CI that (apparently) needs access to OSX' window server (it needs to show a window). After doing some research, it appears that only the currently logged in user and the 'root' user (or SUDO) can access OSX' window server.
The ANT task (Adobe ADL) is one that actually 'runs' a build, so it has to popup a screen.
I'm on a macBook running OSX 10.7.something (Lion), Jenkins 1.487, Ant 1.8.4.
What i have tried so far:
to start with, tried the 'barebone' < exec > task to invoke ADL. Works, but getting error that means that Jenkins running as daemon (with homedir /Users/shared/Jenkins/Home) cannot access OSX' Window Server.
Run Jenkins as myself, by changing USER_NAME, GROUP_NAME, JENKINS_HOME in the jenkins launchd.conf file: https://wiki.jenkins-ci.org/display/JENKINS/Thanks+for+using+OSX+Installer
this gives a lot of errors/trouble, which i tried to solve in communication with the creator of the Jenkins CI but, unfortunately to no avail.
Try to have Ant run an < exec > task (running a shell script) in which i try to sudo with a password using this sneaky way of passing a password to the stdinput: echo < password > | sudo -S < command > which is really bad, but as i'm running Jenkins locally (not reachable from the outside of my LAN) it's np.
Tried to have Ant run an < exec > task, using a 'redirector' with as inputstring my password. also superbad, but yea, i just want it to work. which it did not.
Tried a Jenkins SSH plugin: didn't work. I could, however, SSH to my own localhost using terminal, thing is, i don't know what the Jenkins SSH was trying to do (how can i figure that out anyway?) so i don't know why it wouldn't work.
Tried to have Ant run an SSHEXEC task (which, after some hours, finally worked. Ant for mac is borked, something with optional .jar tasks not being re-named correctly or something) but i'm getting a "com.jcraft.jsch.JSchException: Auth fail" which i googled for, and can't seem to resolve. only applicable solution is to have sshd accept password auths, did that, still got the same error.
I think what i want to accomplish was NOT worth the 2 days that i spent so far on this problem, although i learned a lot. However, i just want this to work and will not accept defeat, yet :)
My question: have you had to solve a similar problem, how did you go about it? are there any other methods i can try to solve this problem? Is there a method mentioned that should JUST _WORK_ and i did something wrong?
[edit] I have decided to go with the Jenkins standalone app, as i think (for me) this is a nicer solution in total, as my laptop is not a build server. Also, the Jenkins app can start at startup so it actually acts as a local server.
Just a quick guess: if you don't want the interactivity of the script, and the script can do without it, you can try to set the headless mode on the java command-line:
-Djava.awt.headless=true
I have decided to go with the Jenkins standalone app, as i think (for me) this is a nicer solution anyway, as my laptop is not a (headless) build server. Also, the Jenkins app can start at startup so it acts as a server too.

Resources