The manual way of installing jenkins are as below:
curl --silent --location http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo | sudo tee /etc/yum.repos.d/jenkins.repo
sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
while I can use file.managed to replace curl, how do I import the keys as shown above?
BR,
Gavin
What the first step does is install the repo.
You can use pkgrepo.managed to declare the repo.
base:
pkgrepo.managed:
- humanname: Logstash PPA
- name: ppa:wolfnet/logstash
- dist: precise
- file: /etc/apt/sources.list.d/logstash.list
- keyid: 28B04E4A
- keyserver: keyserver.ubuntu.com
logstash:
pkg.installed:
- fromrepo: ppa:wolfnet/logstash
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html
Note that there is a keyid to verify the gpg key.
Related
I'm trying to encrypt a file with sops with github actions, my workflow code is
name: Encrypt application secrets
on:
workflow_dispatch:
jobs:
encrypt:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout#v2
with:
fetch-depth: 1
- name: sops install
run: |
curl -O -L -C - https://github.com/mozilla/sops/releases/download/v3.7.1/sops-v3.7.1.darwin
sudo mv sops-v3.7.1.darwin /usr/bin/sops
sudo chmod +x /usr/bin/sops
- name: upload keystore
run: gpg --import .github/.gpg
- name: encrypt file
run: |
sudo chmod +x /usr/bin/sops
sudo sops --encrypt --in-place .github/application.secrets.yaml
But I get this error
Run sudo chmod +x /usr/bin/sops
sudo chmod +x /usr/bin/sops
sudo sops --encrypt --in-place .github/application.secrets.yaml
shell: /usr/bin/bash -e {0}
/usr/bin/sops: 1: ����
�: not found
/usr/bin/sops: 8: Syntax error: word unexpected (expecting ")")
Is there someone who can help please ?
Following worked for my github pipline (though for decryption purposes):
# main.yaml
...
jobs:
build-publish-deploy:
name: Build, Publish and Deploy
runs-on: ubuntu-latest
steps:
...
- name: Decrypt secret
run: |-
curl -O -L -C - https://github.com/mozilla/sops/releases/download/v3.7.3/sops-v3.7.3.linux
sudo mv sops-v3.7.3.linux /usr/bin/sops
sudo chmod +x /usr/bin/sops
export SOPS_AGE_KEY=${{ secrets.GKE_DWK_SOPS_AGE_KEY }}
sops --decrypt manifests/secret.enc.yaml > manifests/secret.yaml
...
Darwin files are usually for MacOS and you are requesting to run on ubuntu-latest.
I'm trying to use JFrog CLI with CircleCI 2.0 to publish my docker image into my JFrog artifactory, after some research I've found this tutorial: https://circleci.com/docs/1.0/Artifactory/ but it's based on CircleCI 1.0 specification.
my config.yml file currently is:
version: 2
jobs:
build:
docker:
- image: docker:17.05.0-ce-git
steps:
- checkout
- setup_remote_docker
- run:
name: Install dependencies
command: |
apk add --no-cache \
py-pip=9.0.0-r1
pip install \
docker-compose==1.12.0 \
awscli==1.11.76
- run:
name: Setup JFrog
command: |
wget http://dl.bintray.com/jfrog/jfrog-cli-go/1.7.1/jfrog-cli-linux-amd64/jfrog
chmod +x jfrog
./jfrog rt config --url $ARTIFACTORY_URL --user $ARTIFACTORY_USER --apikey $ARTIFACTORY_PASSWORD
docker login -e $ARTIFACTORY_EMAIL -u $ARTIFACTORY_USER -p $ARTIFACTORY_PASSWORD $ARTIFACTORY_DOCKER_REPOSITORY
But I'm getting the following error:
#!/bin/sh -eo pipefail
wget http://dl.bintray.com/jfrog/jfrog-cli-go/1.7.1/jfrog-cli-linux-amd64/jfrog
chmod +x jfrog
./jfrog rt config --url $ARTIFACTORY_URL --user $ARTIFACTORY_USER --apikey $ARTIFACTORY_PASSWORD
docker login -e $ARTIFACTORY_EMAIL -u $ARTIFACTORY_USER -p $ARTIFACTORY_PASSWORD $ARTIFACTORY_DOCKER_REPOSITORY
Connecting to dl.bintray.com (35.162.24.14:80)
Connecting to akamai.bintray.com (23.46.57.209:80)
jfrog 100% |*******************************| 9543k 0:00:00 ETA
/bin/sh: ./jfrog: not found
Exited with code 127
Does anyone know what is the correct way to use JFrog CLI with CircleCI 2.0?
I've fixed this installing JFrog CLI through npm:
version: 2
jobs:
build:
docker:
- image: docker:17.05.0-ce-git
steps:
- checkout
- setup_remote_docker
- run:
name: Install dependencies
command: |
apk add --no-cache \
py-pip=9.0.0-r1 \
openssl \
nodejs
pip install \
docker-compose==1.12.0 \
awscli==1.11.76
- run:
name: Setup JFrog
command: |
npm install -g jfrog-cli-go
jfrog rt config --url $ARTIFACTORY_URL --user $ARTIFACTORY_USER --apikey $ARTIFACTORY_PASSWORD
docker login -u $ARTIFACTORY_USER -p $ARTIFACTORY_PASSWORD $ARTIFACTORY_DOCKER_REPOSITORY
Now it's working.
As an alternative to installing with Node.js (which is perfectly possible too, especially if you're running a Node.js build in CircleCI), you can use a cURL command to install it for you.
curl -fL https://getcli.jfrog.io | sh
This script will download the latest released version of the JFrog CLI based on your operating system and your architecture (32 vs 64 bits).
I'm having some problems running Gcloud's Datastore emulator in Travis-ci.
Now running it like:
script:
- export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)"
- echo "deb http://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
- curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
- sudo apt-get update && sudo apt-get install google-cloud-sdk
- nohup gcloud beta emulators datastore start &
But this seems less than ideal.
Not sure what is wrong with this setup, as you say it is 'less than ideal', which indicates that it works.
If you want the setup steps to be cleaner, you can install the google-cloud-sdk directly because it's whitelisted by travis:
dist: trusty
apt:
packages:
- google-cloud-sdk
before_script:
- gcloud beta emulators datastore start &
- $(gcloud beta emulators datastore env-init)
I'm getting my feet wet with SaltStack. I've made my first state (a Vim installer with a static configuration) and I'm working on my second one.
Unfortunately, there isn't an Ubuntu package for the application I'd like my state to install. I will have to build the application myself. Is there a "best practice" for doing "configure-make-install" type installations with Salt? Or should I just use cmd?
In particular, if I was doing it by hand, I would do something along the lines of:
wget -c http://example.com/foo-3.4.3.tar.gz
tar xzf foo-3.4.3.tar.gz
cd foo-3.4.3
./configure --prefix=$PREFIX && make && make install
There are state modules to abstract the first two lines, if you wish.
file.managed: http://docs.saltstack.com/ref/states/all/salt.states.file.html
archive.extracted: http://docs.saltstack.com/ref/states/all/salt.states.archive.html
But you could also just run the commands on the target minion(s).
install-foo:
cmd.run:
- name: |
cd /tmp
wget -c http://example.com/foo-3.4.3.tar.gz
tar xzf foo-3.4.3.tar.gz
cd foo-3.4.3
./configure --prefix=/usr/local
make
make install
- cwd: /tmp
- shell: /bin/bash
- timeout: 300
- unless: test -x /usr/local/bin/foo
Just make sure to include an unless argument to make the script idempotent.
Alternatively, distribute a bash script to the minion and execute. See:
How can I execute multiple commands using Salt Stack?
As for best practice? I would recommend using fpm to create a .deb or .rpm package and install that. At the very least, copy that tarball to the salt master and don't rely on external resources to be there three years from now.
Let's assume foo-3.4.3.tar.gz is checked into GitHub. Here is an approach that you might pursue in your state file:
git:
pkg.installed
https://github.com/nomen/foo.git:
git.latest:
- rev: master
- target: /tmp/foo
- user: nomen
- require:
- pkg: git
foo_deployed:
cmd.run:
- cwd: /tmp/foo
- user: nomen
- name: |
./configure --prefix=/usr/local
make
make install
- require:
- git: https://github.com/nomen/foo.git
Your configuration prefix location could be passed as a salt pillar. If the build process is more complicated, you may consider writing a custom state.
I tried to add:
mypack:
pkg:
- installed
- pkgs:
- mercurial
- git
cmd.run:
- name: 'mkdir -p /opt/mypack'
cmd.run: 'hg pull -u -R /opt/mypack || hg clone -R /opt https://...'
cmd.run: 'ln -s /opt/mypack/etc/init.d/xxx /etc/init.d/xxx'
But for some reason this the state seems to execute/install but the commands are not executed, or at least not all of them.
I need a solution to run multiple commands and to fail the deployment if any of these fails.
I know that I could write a bash script and include this bash script, but I was looking for a solution that would work with only the YAML file.
You want this:
cmd-test:
cmd.run:
- name: |
mkdir /tmp/foo
chown dan /tmp/foo
chgrp www-data /tmp/foo
chmod 2751 /tmp/foo
touch /tmp/foo/bar
Or this, which I would prefer, where the script is downloaded from the master:
cmd-test:
cmd.script:
- source: salt://foo/bar.sh
- cwd: /where/to/run
- user: fred
In addition to the above (better) suggestions, you can do this:
cmd-test:
cmd.run:
- names:
- mkdir -p /opt/mypack
- hg pull -u -R /opt/mypack || hg clone -R /opt https://...
- ln -s /opt/mypack/etc/init.d/xxx /etc/init.d/xxx
For reasons I don't understand yet (I'm a Salt novice), the names are iterated in reverse order, so the commands are executed backwards.
You can do as Dan pointed out, using the pipe or a cmd.script state. But it should be noted that you have some syntax problems in your original post. Each new state needs a name arg, you can't just put the command after the colon:
mypack:
pkg:
- installed
- pkgs:
- mercurial
- git
cmd.run:
- name: 'my first command'
cmd.run:
- name: 'my second command'
However, that actually may fail as well, because I don't think you can put multiple of the same state underneath a single ID. So you may have to split them out like this:
first:
cmd.run:
- name: 'my first command'
second:
cmd.run:
- name: 'my second command'
As one of the users pointed out above, this works in proper order (salt 3000.2)
install_borg:
cmd.run:
- names:
- cd /tmp
- wget https://github.com/borgbackup/borg/releases/download/1.1.15/borg-linux64
- mv borg-linux64 /usr/local/bin/borg
- chmod u+x /usr/local/bin/borg
- chown root:root /usr/local/bin/borg
- ln -s /usr/local/bin/borg /usr/bin/borg
- unless: test -f /usr/bin/borg