When i run this command by ssh into aws instance
docker run hello-world
aws ecr get-login --no-include-email --region ap-south-1 > ./login
source ./login
it output
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /home/ubuntu/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
Which is success.
But when enter same command in jenkins like
output is
I added user by
sudo usermod -a -G docker jenkins
sudo usermod -a -G docker user
What is going wrong ?
source isn't a standard shell command; it's not one of the "special built-in utilities" in the POSIX.1 spec. Some shells happen to have a command named source but it's not required to be present.
There is a similar standard command . that executes a file in the context of the current shell. If you're using the bash-specific source, you can usually just change that to the standard . without making any further changes
. ./login
Note that . searches $PATH for the file to run; it will not search the current directory unless specifically told to. Also note that you typically only use . for scripts that have side effects like setting environment variables, and in a context like what you show where each command is running in a separate shell, this won't have longer-lasting effects.
Since the output of the aws ecr get-login command is a single docker login command that doesn't directly change the shell context, you can also just run it as a shell script
sh ./login
Related
I want to run docker build command in Jenkins shell prompt.
Have already installed docker and add Jenkins user in docker usergroup.
But when i hit docker build command it shows me permission denied issue and when i am using sudo prefix it ask for password with -S argument.
I am running all commands on Jenkins master, earlier i used on other node server not master.
So what is best way to resolve this.
Here is my script:
mogo()
{
sshpass -p 'abc123' ssh -tt -q -o StrictHostKeyChecking=no admin#192.168.10.145 <<'SSH_EOF'
sudo docker exec -it $(sudo docker ps --filter name=mongo --format "{{.Names}}") bash -c "mongodump -d saas -u abc -p abc123 -o md1/"
logout
SSH_EOF
touch /home/admin/11jul20
}
I am calling above script using cronjob for taking backup.
Issue: the process created by the above script hangs forever and
the touch command after logout is not executed.
Manual workaround: If I terminate the process manually with the kill command. The touch command is running and the file 11jul20 got created.
If I remove single quotes '' to 'SSH_EOF' sudo docker command not taking backup, but the touch command is running.
Kindly help me to understand what is wrong.
I suspect that your issue is related to the password request of sudo going to the pseudo terminal specified by your ssh -tt (which is not a real terminal).
I avoid sshpass and never install it (it's a security risk) so I can't test your script.
However, the following will work.
Make your ssh login account part of the docker group
sudo usermod -a -G admin docker
As an aside, instead of using an 'admin' account, it would be a lot more secure to create a special login account (maintenance) on your linux box that can perform only the admin tasks needed.
User the following script
mogo()
{
ssh -T -q -o StrictHostKeyChecking=no admin#192.168.10.145 <<SSH_EOF
docker exec -it \$(docker ps --filter name=mongo --format "{{.Names}}") bash -c "mongodump -d saas -u $MGO_USER -p $MGO_PWD -o md1/"
logout
SSH_EOF
touch /home/admin/11jul20
}
Note that there is no need for pseudo terminal so we disable it (-T). I'd also look at not disabling StrictHostKeyChecking.
3. Set your env.
Keep your passwords and other secrets as environment variables (12 factors), never in your scripts. That's a minimum.
For instance, the following will be injected in your heredoc script.
IMPORTANT make sure you don't use single quotes around SSH_EOF, otherwise the var replacement isn't performed.
export MGO_USER=abc
export MGO_PWD=abc123
Docker has also a secrets store and other open source vaults are available, but with more complexity.
Call your backup script
mgo
Currently we have many Jenkins job which use the username and password credentials variables, which are then passed into a docker container as environment variables by a shell script. The docker container then PULLS source code from bit bucket using these credentials and performs the builds. This is working great, but now we have to switch over to use SSH Username with Key.
I've set these credentials up in Jenkins and its pulling down the source code, attempting to trigger the docker build but getting stuck here as I cant seem to send those credentials then over to the docker container.
Is anyone able to provide some guidance?
Within the Jenkins job is a shell script which basically runs the below:
docker run --rm \
-e JOB="build-release" \
-e LOG_FOLDER=$logDirectory \
-v $logDirectory:$logDirectory \
-e TEMP_FOLDER=$tempFolder \
-v $tempFolder:$tempFolder \
-e BRANCH_NAME=$branch \
-v /var/run/docker.sock:/var/run/docker.sock \
dtr.com/test/checkout-build
There were previously bitbucket username and password variables passed above which had been removed.
The error being thrown within the docker container is:
'Please make sure you have the correct access rights
and the repository exists.
Host key verification failed.'
I had assumed by mapping the /var/run/docker.sock, that the docker deamon would be able to communicate with the machine hosting the docker, and use its ssh keys to access bitbucket, but I guess not :(
I'm new to CI / CD and I'm trying with CircleCI to build and push my app on DockerHub.
I researched some things on the internet, and tried some things, without success.
I'm having an error:
#!/bin/bash -eo pipefail
sudo docker login -u $DOCKER_LOGIN -p $DOCKER_PASSWORD
sudo docker tag $HUB_NAME $DOCKER_LOGIN/$HUB_NAME
sudo docker push $DOCKER_LOGIN/$HUB_NAMEr
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Exited with code 1
My config-yml where I am having trouble:
# run tests!
- run: mvn integration-test
- setup_remote_docker
- run:
name: Build and deploy docker images
command: |
docker build -t $HUB_NAME:latest .
- deploy:
name: Push application Docker image
command: |
sudo docker login -u $DOCKER_LOGIN -p $DOCKER_PASSWORD
sudo docker tag $HUB_NAME $DOCKER_LOGIN/$HUB_NAME
sudo docker push $DOCKER_LOGIN/$HUB_NAME
It seems to me you should not be using sudo docker in your login, tag and push commands.
Just use docker login, docker tag and docker push without sudo and you should be good to go.
Explanation
The whole point of the setup_remote_docker step, which you are using in your configuration, is to set the environment variables that allow the docker command to access a remote docker environment with the current docker user.
In your pipeline output, if you open the step with the label Setup a remote Docker engine, you'll likely see an output like:
Allocating a remote Docker Engine
[ ... skip some output ...]
Remote Docker engine created. Using VM '...'
Created container accessible with:
DOCKER_CERT_PATH=/tmp/docker-certs(...)
DOCKER_HOST=tcp://XXX.XXX.XXX.XXX:YYYY
DOCKER_MACHINE_NAME=ZZZZ
DOCKER_TLS_VERIFY=1
NO_PROXY=127.0.0.1,localhost,circleci-internal-outer-build-agent,XXX.XXX.XXX.XXX:YYYY
[ ... some more output ...]
If you sudo into another user, you'll be missing out on those environment variables, and the docker command will attempt to connect to the standard docker unix socket in the local machine. Which is why you see:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Check the Building Docker Images documentation to see that they don't use sudo anywhere.
You probably copied those sudo commands from your own environment where your local machine restricts access to the docker unix socket.
I have a Jenkins job with the following commands under "Execute shell":
ssh jenkins#172.31.12.58
pwd
I want the Jenkins server to connect via SSH to the remote server then run a command on the remote server.
Instead, Jenkins connects to the remote server, disconnects immediately, then runs the pwd command locally as can be seen in the output:
Started by user Johanan Lieberman
Building in workspace /var/lib/jenkins/jobs/Test Github build/workspace
[workspace] $ /bin/sh -xe /tmp/hudson266272646442487328.sh
+ ssh jenkins#172.31.12.58
Pseudo-terminal will not be allocated because stdin is not a terminal.
+ pwd
/var/lib/jenkins/jobs/Test Github build/workspace
Finished: SUCCESS
Edit: Any idea why the subsequent commands after the ssh command aren't run inside the SSH shell, but rather run locally instead?
If you're not running interactively, SSH does not create an interactive session (thus the "Pseudo-terminal" error message you see), so it's not quite the same as executing a sequence of commands in an interactive terminal.
To run a specific command through an SSH session, use:
ssh jenkins#YOUR_IP 'uname -a'
The remote command must be quoted properly as a single argument to the ssh command. Or use the bash here-doc syntax for a simple multi-line script:
ssh jenkins#YOUR_IP <<EOF
pwd
uname -a
EOF
I think you can use the Publish Over SSH plugin to execute commands on a slave with SSH:
If the Source files field is mandatory, maybe you can transfer a dummy file.
Update:
Another solution is to use the SSH plugin. Maybe it's a better solution compare to the other plugin :)