Author: devopsunleashed

JENKINS JCasC – securityRealm

I just can’t stop playing around with the Jenkins JCasC plugin.  However, I just don’t think its in a state to replace all of your Jenkins configuration yet.

Example – I want to create a new Jenkins user\password and add the additional user data such as email, token, and description with the JCasC plugin.

You are currently only able to automate the username and password, and that is it.

  securityRealm:

    local:

      allowsSignup: false

      enableCaptcha: false

      users:

      - id: "builduser"

        password: ${builduserpassword}

If you try adding the additional attributes, its going to fail.  Checking the code seems to confirm the only available values are username and password.

Anyways, I will be following this plugin very closely.  Probably even test it out more…

jenkins

Jenkins – Configuration as Code – JCasC

I have been doing a little research on the Jenkins Configuration as Code (JCasC) plugin and I must say I think it’s definitely a step in the right direction.

In theory, with this plugin, you can have the majority of your Jenkins configuration stored in 1 file.  This file can then be put in source control, which would allow you to easily rebuild your Jenkins instance at anytime.

However, while playing around with the plugin, a couple things came to my mind.

  1. It was hard for me to determine the correct syntax that needed to go into my jenkins.yaml file.  There are examples located here, but these weren’t enough for me to get moving quickly.
  2. Long term, it could be a bit cumbersome to make all changes in the yaml file correctly, then re-apply to Jenkins instances.
  3. If the examples and plugin mature more, this is surely a easy way for teams to fail-safe\share their Jenkins configuration
  4. Fixing or growing the jenkins.yaml export functionality would greatly help.  This would essentially allow you to apply Jenkins changes manually, then export to see the correct yaml syntax.

Anyways – This is a cool plugin that I am surely looking forward to using in the future!

jenkins.png

SQS (S3 Event) Lambda Trigger

I ran into a little issue today parsing a S3 SQS event that was sent to Lambda via a SQS trigger.  I assumed the incoming event to Lambda was 100% of type dict.  Given this, I assumed I could pull the bucket name and key using this syntax.

bucketname = event['Records'][0]['body']['Records'][0]['s3']['bucket']['name']
objectname = event['Records'][0]['body']['Records'][0]['s3']['object']['key']

As it turns out the incoming event is not 100% of type dict and I got the following error.  

string indices must be integers

The Records after the body ([‘Records’][0][‘body’]) are of type str.  Below is the updated code to pull the bucket name and key from the incoming event.

event_body_records_string = event['Records'][0]['body']
event_body_records_dict = json.loads(event_body_records_string)

bucketname = event_body_records_dict['Records'][0]['s3']['bucaket']['name']
objectname = event_body_records_dict['Records'][0]['s3']['object']['key']

Now everything works out great!!!

python