I am configuring an installation of Jenkins through JCasC. One of the plugins we're using is Kubernetes.
In order to configure, it needs a server certificate to communicate with the k8s cluster.
This is how that part of the config looks like:
jenkins:
clouds:
-kubernetes:
name: "kubernetes"
serverUrl: "k8s URL"
serverCertificate: "serverCertificate"
skipTlsVerify: true
I am wondering how I can reference a file that contains the server certificate and put that file at the serverCertificate.
I would recommend you to rather use a predefined [jenkins] credentials:
and reference them inside JCasC pipeline as a way of accessing Kubernetes cluster.
jenkins:
clouds:
- kubernetes:
name: "advanced-k8s-config"
serverUrl: "https://avanced-k8s-config:443"
skipTlsVerify: true
namespace: "default"
credentialsId: "advanced-k8s-credentials"
jenkinsUrl: "http://jenkins/"
...
credentials:
system:
domainCredentials:
- credentials:
- fileSystemServiceAccountCredential:
id: "advanced-k8s-credentials"
Please check here for full code example.
Related
I am trying to create a user and password for Jenkins using JCASC. I can set up Jenkins however when I go to the GUI on my local host I do not see any users. Here is my code
jenkins:
systemMessage: "Jenkins configured automatically by Jenkins Configuration as Code plugin\n\n"
disabledAdministrativeMonitors:
- "jenkins.diagnostics.ControllerExecutorsNoAgents"
credentials:
system:
domainCredentials:
- credentials:
- usernamePassword:
id: "admin-cred"
username: "jenkins-admin"
password: "butler"
scope: GLOBAL
I believe I have all the necessary plugins installed but something is missing clearly. Any help would be appreciated.
The way I got users to pop up is by setting up the (local) security realm, rather than credentials, like so:
jenkins:
securityRealm:
local:
users:
- id: jenkins-admin
password: butler
I'm finding this a great resource to get ideas from: https://github.com/oleg-nenashev/demo-jenkins-config-as-code
I've used a local security Realm with disabled signups to add the user "jenkins-admin".
jenkins:
. . .
securityRealm:
local:
allowsSignup: false
users:
- id: jenkins-admin
password: butler
You can refer below links to know more about Jcasc:
https://www.jenkins.io/projects/jcasc/
https://github.com/jenkinsci/configuration-as-code-plugin
I want to setup a Jenkins job which should be triggered by Rundeck. I have already installed Rundeck plugin and tested the connection between Rundeck and Jenkins which is working as expected.
Now, my requirement is that the same Jenkins job should be triggered by Rundeck. I am using Rundeck 3.4.9 community version.
How can I setup a Jenkins job in Rundeck and what configurations I need to do on both Rundeck and Jenkins end?
You can design a Rundeck job that call the Jenkins job using this endpoint via CURL.
I tested successfully with this endpoint:
http://user:JENKINS_USER_TOKEN#localhost:8080/job/TestJob/build
You can use the http workflow step to send post requests using that URL format.
Source.
Here is a job definition example:
- defaultTab: nodes
description: ''
executionEnabled: true
id: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
loglevel: INFO
name: ExampleJENKINS
nodeFilterEditable: false
plugins:
ExecutionLifecycle: null
scheduleEnabled: true
sequence:
commands:
- exec: echo "starting..."
- fileExtension: .sh
interpreterArgsQuoted: false
script: curl -vvv -X POST http://admin:11bd72f1f22653cf7158c7961f60476a1d#localhost:8080/job/MyJenkinsJob/build
scriptInterpreter: /bin/bash
keepgoing: false
strategy: node-first
uuid: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
Another way is to use the HTTP Step plugin with a basic authentication configured.
The job definition example:
- defaultTab: nodes
description: ''
executionEnabled: true
id: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
loglevel: INFO
name: ExampleJENKINS
nodeFilterEditable: false
plugins:
ExecutionLifecycle: null
scheduleEnabled: true
sequence:
commands:
- exec: echo "starting..."
- configuration:
authentication: Basic
checkResponseCode: 'false'
method: POST
password: keys/jenkins_admin_token
printResponse: 'false'
printResponseToFile: 'false'
proxySettings: 'false'
remoteUrl: http://localhost:8080/job/MyJenkinsJob/build
sslVerify: 'true'
timeout: '30000'
username: admin
nodeStep: true
type: edu.ohio.ais.rundeck.HttpWorkflowNodeStepPlugin
keepgoing: false
strategy: node-first
uuid: 1fa2923a-5b1d-4ea2-97d1-4cc2a3726f07
I'm having a hard time using custom Elasticsearch ingest pipelines with Filebeat's Docker autodiscovery. I've started out with custom processors in my filebeat.yml file, however I would prefer to shift this to custom ingest pipelines I've created.
Firstly, here is my configuration using custom processors that works to provide custom grok-like processing for my Servarr app Docker containers (identified by applying a label to them in my docker-compose.yml file). The processor copies the 'message' field to 'log.original', uses dissect to extract 'log.level', 'log.logger' and overwrite 'message'. The final processor is a JavaScript function used to convert the log.level to lowercase (overkill perhaps, but humour me).
Filebeat configuration:
filebeat.config:
modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: true
reload.period: 60s
filebeat.autodiscover:
providers:
- type: docker
hints.enabled: true
json.keys_under_root: true
processors:
- if:
equals:
docker.container.labels.co_elastic_logs/custom_processor: servarr
then:
- copy_fields:
fields:
- from: message
to: log.original
fail_on_error: false
ignore_missing: true
- dissect:
tokenizer: "[%{log.level}] %{log.logger}: %{message}"
field: message
target_prefix: ""
overwrite_keys: true
ignore_failure: true
- script:
lang: javascript
id: lowercase
source: >
function process(event) {
var level = event.Get("log.level");
if(level != null) {
event.Put("log.level", level.toString().toLowerCase());
}
}
output.elasticsearch:
hosts: 'elasticsearch:9200'
username: 'elastic'
password: '*************'
setup.kibana.host: 'kibana:5601'
logging.json: true
logging.metrics.enabled: false
Excerpt from docker-compose.yml file...
lidarr:
image: ghcr.io/linuxserver/lidarr:latest
container_name: lidarr
labels:
co.elastic.logs/custom_processor: "servarr"
And an example log line (in json):
{"log":"[Info] DownloadDecisionMaker: Processing 100 releases \n","stream":"stdout","time":"2021-08-07T10:10:49.125702754Z"}
This works well, and achieves my aims of extracting fields, but ideally I'd like to use Elasticsearch's (more powerful) ingest pipelines instead, and live with a cleaner filebeat.yml, so I created a working ingest pipeline "filebeat-7.13.4-servarr-stdout-pipeline" like so (ignore the fact that for now, this only does the grokking):
[
{
"grok": {
"field": "message",
"patterns": [
"\\[%{LOGLEVEL:log.level}\\] %{WORD:log.logger}: %{GREEDYDATA:message}"
],
"trace_match": true,
"ignore_missing": true
}
}
]
I tested the pipeline against existing documents (not ones that have had my custom processing applied, I should note). The pipeline worked against all the documents I tested it against in the Kibana interface.
So now I come to shift my Filebeat config to use this pipeline for containers with my custom_processor label. This is the filebeat.yml I came up with, which is apparently valid and works for the most part, but doesn't apply the grokking:
filebeat.config:
modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: true
reload.period: 60s
filebeat.autodiscover:
providers:
- type: docker
hints.enabled: true
json.keys_under_root: true
appenders:
- type: config
condition.equals:
docker.container.labels.co_elastic_logs/custom_processor: servarr
config:
pipeline: filebeat-7.13.4-servarr-stdout-pipeline
output.elasticsearch:
hosts: 'elasticsearch:9200'
username: 'elastic'
password: '*************'
setup.kibana.host: 'kibana:5601'
logging.json: true
logging.metrics.enabled: false
If I use Filebeat's inbuilt modules for my other containers such as nginx, by using a label such as in this example below, the inbuild module pipelines are used:
nginx-repo:
image: nginx:latest
container_name: nginx-repo
mem_limit: 2048m
environment:
- VIRTUAL_HOST=repo.***.***.***,repo
- VIRTUAL_PORT=80
- HTTPS_METHOD=noredirect
networks:
- default
- proxy
labels:
co.elastic.logs/module: "nginx"
co.elastic.logs/fileset.stdout: "access"
co.elastic.logs/fileset.stderr: "error"
What am I doing wrong here? The logs still end up in Elasticsearch and Kibana, and are processed, but my grok isn't applied, new fields aren't created, and the 'message' field is unchanged.
EDIT: In response to one of the comments linking to a post on the elastic forums, which suggested both the path(s) and the pipeline need to be made explicit, I tried the following filebeat.yml autodiscovery excerpt, which also fails to work (but is apparently valid config):
filebeat.autodiscover:
providers:
- type: docker
hints.enabled: true
json.keys_under_root: true
appenders:
- type: config
condition:
equals:
docker.container.labels.co_elastic_logs/custom_processor: "servarr"
config:
- type: docker
containers:
ids:
- "${data.docker.container.id}"
stream: all
paths:
- /var/lib/docker/containers/${data.docker.container.id}/${data.docker.container.id}-json.log
pipeline: filebeat-7.13.4-servarr-stdout-pipeline
I tried with the docker.container.labels.co_elastic_logs/custom_processor value both quoted and unquoted. I have the same behaviour where the logs end up in Elasticsearch / Kibana, but they are processed as if they skipped my ingest pipeline.
We're using Kubernetes instead of Docker with Filebeat but maybe our config might still help you out.
We have autodiscover enabled and have all pod logs sent to a common ingest pipeline except for logs from any Redis pod which use the Redis module and send their logs to Elasticsearch via one of two custom ingest pipelines depending on whether they're normal Redis logs or slowlog Redis logs, this is configured in the following block:
All other detected pod logs get sent in to a common ingest pipeline using the following catch-all configuration in the "output" section:
Something else that we do is add the name of the ingest pipeline to ingested documents using the "set" processor:
This has proven to be really helpful when diagnosing whether or not a pipeline was actually executed when viewing an event document in Kibana.
My objective is to build Jenkins as a docker image and deploy it to AWS Elastic Beanstalk.
To build the docker image I am using the Configuration as Code plugin and injecting all secrets via environment variables in the Dockerfile.
What I am trying to figure out now is how to automate this deployment using CloudFormation or CodePipeline.
My question is:
Can I fetch secrets from AWS Secrets Manager using either CloudFormation or CodePipeline and inject them as environment variables in the deployment to Elastic Beanstalk?
Not sure why you want to do stuff in this way in general, but couldn't you just use the AWS CLI to get the secrets from Secrets Manager directly from your ELB instance?
Cloudformation templates can recover secrets from Secrets Manager. It is somewhat ugly, but works pretty well. In general, I use a security.yaml nested stack to generate secrets for me in SM, then recover them in other stacks.
I can't speak too much to EB, but if you are deploying that through CF, then this should help.
Generating a secret in SM (CF security.yaml):
Parameters:
DeploymentEnvironment:
Type: String
Description: Deployment environment, e.g. prod, stage, qa, dev, or userdev
Default: "dev"
...
Resources:
...
RegistryDbAdminCreds:
Type: 'AWS::SecretsManager::Secret'
Properties:
Name: !Sub "RegistryDbAdminCreds-${DeploymentEnvironment}"
Description: "RDS master uid/password for artifact registry database."
GenerateSecretString:
SecretStringTemplate: '{"username": "artifactadmin"}'
GenerateStringKey: "password"
PasswordLength: 30
ExcludeCharacters: '"#/\+//:*`"'
Tags:
-
Key: AppName
Value: RegistryDbAdminCreds
Using the secret in another yaml:
Parameters:
DeploymentEnvironment:
Type: String
Description: Deployment environment, e.g. prod, stage, qa, dev, or userdev
Default: "dev"
...
Resources:
DB:
Type: 'AWS::RDS::DBInstance'
DependsOn: security
Properties:
Engine: postgres
DBInstanceClass: db.t2.small
DBName: quilt
MasterUsername: !Sub '{{resolve:secretsmanager:RegistryDbAdminCreds-${DeploymentEnvironment}:SecretString:username}}'
MasterUserPassword: !Sub '{{resolve:secretsmanager:RegistryDbAdminCreds-${DeploymentEnvironment}:SecretString:password}}'
StorageType: gp2
AllocatedStorage: "100"
PubliclyAccessible: true
DBSubnetGroupName: !Ref SubnetGroup
MultiAZ: true
VPCSecurityGroups:
- !GetAtt "network.Outputs.VPCSecurityGroup"
Tags:
- Key: Name
Value: !Join [ '-', [ !Ref StackName, "dbinstance", !Ref DeploymentEnvironment ] ]
The trick is in !Sub '{{resolve:secretsmanager:RegistryDbAdminCreds-${DeploymentEnvironment}:SecretString:username}}' and !Sub '{{resolve:secretsmanager:RegistryDbAdminCreds-${DeploymentEnvironment}:SecretString:password}}'
I am using Ansible for provision our servers, I installed the Jenkins 2.0 but it is becomeing with a startup configuration when I open the web UI. How can I do it with Ansible or shell or jenkins-cli. CentOS 7, Ansible 2.0.1.0.
So,
Installing Jenkins 2.0 from http://pkg.jenkins-ci.org/redhat-rc/jenkins-2.0-1.1.noarch.rpm rpm.
Install java with yum.
Service start jenkins.
Open 192.168.46.10:8080, which is opening the Jenkins.
In Web UI adding the initial admin password.
In web UI select and install plugins.
In web UI create a new admin user.
The 5,6,7 points are all the startup config of the new Jenkins. I haven't idea how we can install it autmatically.
Edit 1:
The 1,2,3 point is already done, just I didn't share because it is not necessary, because I only need an advice how can I configure the Jenkins. But now I add it to my question.
---
- name: Jenkins - install | Install java
yum: name=java state=installed
- name: Jenkins - install | Install Jenkins 2.0
yum: pkg=http://pkg.jenkins-ci.org/redhat-rc/jenkins-2.0-1.1.noarch.rpm state=installed
- name: Jenkins - install | Start and enable Jenkins 2.0
service: name=jenkins state=started enabled=yes
You can create an initialization script (in groovy) to add an admin account.
Script should be present in $JENKINS_HOME/init.groovy.d/*.groovy.
See Jenkins CI Wiki for more details.
Here's an example.
security.groovy.j2 file:
#!groovy
import java.util.logging.Level
import java.util.logging.Logger
import hudson.security.*
import jenkins.model.*
def instance = Jenkins.getInstance()
def logger = Logger.getLogger(Jenkins.class.getName())
logger.log(Level.INFO, "Ensuring that local user '{{ jenkins.admin_username }}' is created.")
if (!instance.isUseSecurity()) {
logger.log(Level.INFO, "Creating local admin user '{{ jenkins.admin_username }}'.")
def strategy = new FullControlOnceLoggedInAuthorizationStrategy()
strategy.setAllowAnonymousRead(false)
def hudsonRealm = new HudsonPrivateSecurityRealm(false)
hudsonRealm.createAccount("{{ jenkins.admin_username }}", "{{ jenkins.admin_password }}")
instance.setSecurityRealm(hudsonRealm)
instance.setAuthorizationStrategy(strategy)
instance.save()
}
How to use in Ansible playbook:
- name: Create initialization scripts directory
file: path={{ jenkins.home }}/init.groovy.d
state=directory
owner=jenkins
group=jenkins
mode=0775
- name: Add initialization script to setup basic security
template: src=security.groovy.j2
dest={{ jenkins.home }}/init.groovy.d/security.groovy
I was inspired by this GitHub reposiotry.
I found a solution, this is turn off the setup wizard, after it I was able to change config files.
- name: Jenkins - configure | Turn off Jenkins setup wizard
lineinfile: dest=/etc/sysconfig/jenkins regexp='^JENKINS_JAVA_OPTIONS=' line='JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"'
notify: restart jenkins
The above solution didn't work for me but give me hint and this is the solution that worked for me on Ubuntu:
- name: Configure JVM Arguments
lineinfile:
dest: /etc/default/jenkins
regexp: '^JAVA_ARGS='
line: 'JAVA_ARGS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"'
notify:
- Restart Jenkins
On Ubuntu 16.04 with Jenkins installed using apt-get, this works:
- name: "Turn off Jenkins setup wizard"
lineinfile:
dest: /etc/init.d/jenkins
regexp: '^JAVA_ARGS='
line: 'JAVA_ARGS="-Djava.awt.headless=true -Djenkins.install.runSetupWizard=false"'
insertbefore: '^DAEMON_ARGS='
notify: restart jenkins
- name: restart jenkins
service: name=jenkins state=restarted
You will still have to setup the security though!