I have 2 questions that Im trying to figure out.
QUESTION 1
I have setup a Jenkins Master and am trying to create a Agent using the UI. Here is the UI snippet.
Now when I click Save and open the Agent, it tells me to use this command to conenct.
java -jar agent.jar -jnlpUrl https://<MASTER_NODE>/computer/Test_node/slave-agent.jnlp
It is not giving me the option to use -secret. How can I enable that feature so that I also need to provide the secret to connect to my master.
QUESTION 2
I am in the process of automating the creation of multiple Jenkins Agents. Im going to do that using REST API calls. The command is
curl -s -k -w %{http_code} -X POST "https://<MASTER_NODE>/computer/doCreateItem?name=jenkins-slave-1&type=hudson.slaves.DumbSlave" \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "Jenkins-Crumb: ${JENKINS_CRUMB}" \
-d "json=${JNLP_JSON}" )
Now the thing is for every agent, the secret value inside the jnlp file is different. Is there a way to specify that value in the Jenkins Master so that every Jenkins Agent has the same password ?
If you are the jenkins admin, check
1) Manage Jenkins -->Configure Global Security-->Access Control-->Authorization
under Project-based Matrix Authorization Strategy, make sure you have not ticked the Connect options under Agent for Anonymous role.
(or)
2) Make sure Manage Jenkins--> Configure Global Security-->Agents-->Agent protocols has only V4 enabled
JNLP V4 TLS based encryption
As for your second question I do not know. am facing the same issue of how to connect the slaves automatically to the Jenkins Master with different Secrets
JNLP Secrets are derived from the Agent's name. You could get the JnlpMac or secret for a specific agent from the jnlp file or via groovy executed on the master. See for example How to find JNLP Node's secret key remotely?
You can add jenkins-slave.exe and jenkins-slave.xml in Remote root directory which contains jre argument this need a secret key. Secret key only needed when you are setting agent as windows service.
I have followed instruction in LINK
Related
I wanted to have a bot integrated with slack, using which my team can run Jenkins builds. I tried doing it using hubot, following the steps here: https://slack.dev/hubot-slack/
I mentioned all the variables (jenkins_url, jenkins auth -username:password, slack token) in .bashrc and sourced it. The bot connected to slack and when run #hunot help, it will list all the options. So far so good.
I also included jenkins.coffee script in hubot-scripts.json, to reach jenkins however, I'm unable to connect to jenkins. When I run #hubot help, it lists jenkins commands as well. The problem arises when I actually run one of those jenkins commands. When I run #hubot jenkins list, it returns Jenkins says: Error: connect ECONNREFUSED 127.0.0.1:80
I'm not sure what the issue is. On my jenkins host, I'm using nginx, reverse proxy (so that I don't have to use 8080 in url while accessing jenkins). Is there something obvious I'm missing?
Also, how can I access jenkins without user and password?
I am trying to start a VM that already exist in Google cloud with my jenkins to use it as a slave. The reason is because if I start the template of this VM I need to do a few things before I can use my Jenkins code.
Does anyone know how to start VM's that already exist in my VM Pool in Google Could via Jenkins?
There might be 2 approaches to this depending on the operations that you need to run before in your machine that is preventing you from just recreating it.
First and possibly the most straightforward given the restriction that the machine already exists would be talking directly to the GCE API in order to list and start the machine from Jenkins (using a build step).
Basically you can make requests to the GCE API to do operations with your instances. I suggest doing this using gcloud from within the Jenkins master node as it'll save you having to write your own client. It's straightforward as you only have to "install" it in your master and you can make it work safely using a service account.
Below is the outline of this approach:
Download the cloud-sdk to your master node following these release instructions.
You can do this once outside of Jenkins or directly in the build step, doesn't matter as long as Jenkins and its user is able to get the binary.
Create the service account, generate authentication keys and give it permissions to interact with GCE.
Using a service account is the way to go as you can restrict its permissions to the operations that are relevant for you.
Once you get the service account that will be bound to your gcloud client, you'll need to set it up in Jenkins. You might want to do this in a build step (I'm using Groovy here but it should be easy to translate it to the UI):
stage('Start_machine'){
steps{
//Considering that you already installed gcloud in this node, but you can also curl it from here if that's convenient
// You can set this as an scope env var in Jenkins or just hard code it
gcloud config set project ${GOOGLE_PROJECT_ID};
// This needs a json file location accessible by jenkins like: --key-file /var/lib/jenkins/..key.json
gcloud auth activate-service-account --key-file ${GOOGLE_SERVICE_ACCOUNT_KEY};
// Check the reference on this command: https://cloud.google.com/sdk/gcloud/reference/compute/instances/start
gcloud compute instances start my_existing_instance;
echo "Instance started"
}
post{
always{
println "Result : ${currentBuild.result}";
}
}
Wrapping up: You basically create a service account that has the permissions to start your instances. Download an client that can interact with the GCE API (gcloud), authenticate it and start the instance, all from within your pipeline.
The second approach might be easier if there were no constraints regarding the preexisting machine.
Jenkins has a plugin for Compute Engine that will automatically spin up new workers whenever needed.
I know that you need to do some previous operations before Jenkins sends some work to these slave machines. However, I want to bring to your attention that this plugin also considers the start up scripts.
So there's always the option to preload your operations there before the machine takes off and by the time it's ready, you might have everything done.
Hope this helps.
I'm new to Google Cloud Platform and want to build a deployment pipeline via Jenkins. I have a virtual machine up and running that I connect via SSH button given on the dashboard and do deployments.
Unlike AWS where I get pem file to connect... I don't have a file to connect here. Now, in Jenkins when I want to connect via shell script and deploy latest code on VM - I don't know how to do it.
something like
ssh -i #some-file name:ip
Kindly help as to how can I connect/ssh gcp vm via shell in Jenkins and make deployments. Step by step answer needed. Thanks!
There are still PEM files stored in the VM instance, you can locate them in $HOME/.ssh.
See this stack post about how to retrieve SSH keys on GCE
How do I trigger builds remotely?
I followed some tutorial and ready with this below:
Curl user `sanveen:585da82e7d3df2991dea3533ea794d06 `
The M link format is http://localhost:8080/jenkins/job/triggerbuild/build?token=gitbitsolution6789
The authentication token set in the jenkins-plugins section.
But where do I call this and trigger the build?
Let's suppose you have two machines A and B. On machine A Jenkins is configured. And your purpose is to trigger builds from machine B. In order to do that you configure Jenkins to allow builds using scripts. And make HTTP POST requests to machine A from machine B.
To send POST requests to machine B, you can make use of curl and create a Bash script to trigger a build.
For example,
curl -X POST http://API_TOKEN_USER_ID:API_TOKEN#your-jenkins.com/job/JobName/build?token=AUTHENTICATION_TOKEN
I'm using the jenkins-cli.jar file from my jenkins server, and on every run it prompts me for my ssh key passphrase. I'd like it to use my ssh keychain so I don't have to enter it on every invocation.
If it matters, I'm on OSX using the default keychain setup, I don't have a manual ssh-agent configured right now.
Jenkins CLI client does not support SSH agents for now.
As a workaround, you can generate dedicated key without passphrase, associate it with your Jenkins account and instruct client to use that key on every invocation.