I'm trying to install syndesis on minishift following the official guides.
Installed minishift on ubuntu, no issues. Next I've tried
./syndesis minishift --install. In the end it says I have to run local dev builds for sysdesis-server syndesis-ui, etc
./syndesis build --app-images but got some dependency errors
Run syndesis quickstart. All the pods are up except syndesis-server. It doesn't start due to error like UnknownHostException: syndesis-db in the migration bean
Also tried ./syndesis minishift --install --tag 1.8.12 to install stable version but not sure if I'm doing it right cause no success
Any help ?
Sorry for the late response. We moved to use an Operator to do the installation and it caused a bunch of installation issues. If you have minishift installed then on Linux or Mac you should be able to get Syndesis installed using
bash <(curl -sL https://syndes.is/start)
See also: https://github.com/syndesisio/syndesis-quickstarts/blob/master/README.md#3-install-syndesis
It uses the syndesis bash command line tool from (https://github.com/syndesisio/syndesis/blob/master/tools/bin/), so you can check out the code yourself too and run that using:
./.syndesis/bin/syndesis minishift --install --full-reset --nodev --open
and then you can explore other options to specify a tag if you want.
Hope this gets you going!
Cheers,
--Kurt
A colleague of mine removed mysqli driver in one of our Dockerfile for PHP hosting and it causes problem. Luckily it is discovered in staging environment.
Is there any tools our there that does unit testing for docker images and if there are certain unavailability of an essential driver, fail it in the CI/CD pipeline?
Download the latest shaded dist from https://github.com/dgroup/docker-unittests/releases:
wget https://github.com/dgroup/docker-unittests/releases/download/s1.1.1/docker-unittests-app-1.1.1.jar
De fine an *.yml file with tests.
version: 1.1
setup:
- apt-get update
- apt-get install -y tree
tests:
- assume: java version is 1.9, Debian build
cmd: java -version
output:
contains:
- openjdk version "9.0.1"
- build 9.0.1+11-Debian
- assume: curl version is 7.xxx
cmd: curl --version
output:
startsWith: curl 7.
matches:
- "^curl\\s7.*\\n.*\\nProtocols.+ftps.+https.+telnet.*\\n.*\\n$"
contains:
- AsynchDNS IDN IPv6 Largefile GSS-API
- assume: Setup section installed `tree`
cmd: tree --version
output:
contains: ["Steve Baker", "Florian Sesser"]
Run tests for image
java -jar docker-unittests.jar -f image-tests.yml -i openjdk:9.0.1-11
https://i.stack.imgur.com/DSv72.png
More you can find in https://github.com/dgroup/docker-unittests.
Feel free to submit new issues/questions/etc.
Did you know about Google's tool for testing container images - container-structure-test?
This utility can be easily integrated in CI/CD pipeline as artifact check step.
After updating gcloud I get this warning, but how do I do it(Should I remove Docker)?
WARNING: There are older versions of Google Cloud Platform tools on your system PATH.
Please remove the following to avoid accidentally invoking these old tools:
/Applications/Docker.app/Contents/Resources/bin/kubectl
I have this in my .zshrc:
# The next line updates PATH for the Google Cloud SDK.
if [ -f '/Users/<NAME>/google-cloud-sdk/path.zsh.inc' ]; then source '/Users/<NAME>/google-cloud-sdk/path.zsh.inc'; fi
# The next line enables shell command completion for gcloud.
if [ -f '/Users/<NAME>/google-cloud-sdk/completion.zsh.inc' ]; then source '/Users/<NAME>/google-cloud-sdk/completion.zsh.inc'; fi
[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh
This happens because docker-for-mac installs a bin for kubectl, and gcloud-sdk also installs another bin with gcloud components install kubectl.
My recommendation is to uninstall kubectl as component from gcloud, overwrite the symlink from docker-for-mac, and only use the homebrew installed bin.
Try this commands:
gcloud components remove kubectl
brew install kubernetes-cli
brew link --overwrite kubernetes-cli
TLDR
/usr/local/bin/kubectl is a link installed by Docker: ls -l /usr/local/bin/kubectl => /usr/local/bin/kubectl -> /Applications/Docker.app/Contents/Resources/bin/kubectl. Removing the link has no side effects and solves the conflict:
rm /usr/local/bin/kubectl
Justification
The conflict is with the Docker-provided version of kubectl so it makes sense to check what Docker docs have to say about it. https://docs.docker.com/desktop/kubernetes/#use-the-kubectl-command
Extract:
If you installed kubectl using Homebrew, or by some other method, and experience conflicts, remove /usr/local/bin/kubectl.
Here is my case you can refer to. After running gcloud components update, I got this warning:
WARNING: There are older versions of Google Cloud Platform tools on your system PATH.
Please remove the following to avoid accidentally invoking these old tools:
/usr/local/Cellar/kubernetes-cli/1.10.2/bin/kubectl
I check this tool using brew list
☁ issue [master] brew list
coreutils gdbm git-lfs icu4c kops kubectx libpng mtr openssl python#2 sqlite tree wxmac
erlang geoip git-redate jpeg kube-ps1 kubernetes-cli libtiff node pcre readline telnet watchman
After reading the doc. I decided to uninstall kubernetes-cli and its dependencies kops, kube-ps1, and kubectx to avoid the conflicts.
☁ issue [master] brew uninstall kops kube-ps1 kubectx
Uninstalling /usr/local/Cellar/kops/1.9.0... (5 files, 129.8MB)
Uninstalling /usr/local/Cellar/kube-ps1/0.6.0... (6 files, 29.0KB)
Uninstalling /usr/local/Cellar/kubectx/0.5.0... (12 files, 27.8KB)
☁ issue [master] brew uninstall kubernetes-cli
Uninstalling /usr/local/Cellar/kubernetes-cli/1.10.2... (178 files, 52.8MB)
☁ issue [master] gcloud components update
All components are up to date.
This warning is gone.
I just went into the Docker file's bin folder and moved the kubectl to the trash.
Do echo $PATH and check which folder takes precedence. In my case it is like .../Users/myname/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:.... Here the kubectl in gcloud is actually before the kubectl from Docker Desktop (which is in /usr/local/bin/kubectl) so there is no problem. If this is also your case you don't need to do anything.
Of course, if you want to completely remove confusion you can just delete the link /usr/local/bin/kubectl -> /Applications/Docker.app/Contents/Resources/bin/kubectl, or rename it.
Update:
In the recent docker desktop releases they actually provided another link /usr/local/bin/kubectl.docker -> /Applications/Docker.app/Contents/Resources/bin/kubectl to differentiate it from other kubectl so it is not a bad idea to just simply delete the link /usr/local/bin/kubectl -> /Applications/Docker.app/Contents/Resources/bin/kubectl
After the latest updates to gcloud and docker I'm unable to access images on my google container repository. Locally when I run: gcloud auth configure-docker as per the instructions after updating gcloud, I get the following message:
WARNING: `docker-credential-gcloud` not in system PATH.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.
gcloud credential helpers already registered correctly.
Running which docker-credential-gcloud returns docker-credential-gcloud not found.
I have no other gcloud-related path issues and for the life of me can't figure out how to install/add docker-credential-gcloud to path. Here's what I have installed (shown via gcloud version):
Google Cloud SDK 197.0.0
beta 2017.09.15
bq 2.0.31
container-builder-local
core 2018.04.06
docker-credential-gcr
gsutil 4.30
I also have Docker CE Version 18.03.0-ce-mac60 (23751).
Here's my $PATH:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
I also ran source /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc on original gcloud install.
Notice: All docker-credential-gcr below can be replaced with docker-credential-gcloud. I think it is just different versions of gcloud, I might be wrong.
I used Homebrew Cask to install gcloud too. I installed docker-credential-gcr with
$ gcloud components install docker-credential-gcr
And then like you said, which docker-credential-gcr doesn't gave you anything.
So I ran which gcloud to find there is a symlink to gcloud in /usr/local/bin. This symlink is created by Homebrew when you installed gcloud at first place. Now docker-credential-gcr wasn't installed by Homebrew but by gcloud itself, so there isn't a symlink.
I called readlink /usr/local/bin/gcloud and found out gcloud is installed in /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/.
Then:
$ ls /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin
There you should see docker-credential-gcr listed there.
I simply linked it to /usr/local/bin:
$ ln -s \
/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/docker-credential-gcr \
/usr/local/bin/
Then run:
$ docker-credential-gcr configure-docker
It should succeed.
Just had the same issue on Windows, running Docker with Linux containers, Docker engine v19.03.8. Using docker compose. I do not use gcloud for my dockerfiles...
DT1001 dockerpycreds.errors.InitializationError:
docker-credential-gcloud not installed or not available in PATH
Option 1: Edit the docker configuration file and remove all gcloud entries from there.
Windows c:/Users/<your account>/.docker/config.json
Linux & MacOS ~/.docker/config.json
Option 2: Go to Troubleshoot -> Reset to factory defaults.
After this my docker compose was creating containers and running the images without any issues.
On MacOS
Step 1：
Install gcloud and docker-credential-gcr,
following this tutorial
Step 2:
$ ln -s /usr/local/google-cloud-sdk/bin/docker-credential-gcr /usr/local/bin/docker-credential-gcloud
Step 3:
$ rm -rf ~/.docker
Step 4:
$ docker-compose build --pull
Finished!
Never found a way to directly resolve the docker-credential-gcloud issue, but the following got me up and running again. WARNING: the following will delete all your existing docker images and install a bunch of gcloud utilities:
gcloud components install docker-credential-gcr,
Restart the terminal completely
docker-credential-gcr configure-docker.
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
umount /var/lib/docker/overlay2
rm -rf /var/lib/docker
Restart the terminal completely.
The new version of google-cloud-sdk has only docker-credential-gcr but not docker-credential-gcloud anymore. On the other hand one of my python packages always requested docker-credential-gcloud.
The solution was to symlink docker-credential-gcloud to docker-credential-gcr:
ln -s /path/to/google-cloud-sdk/bin/docker-credential-gcr /usr/local/bin/docker-credential-gcloud
ls -l /usr/local/bin | grep docker should now print:
...
docker-credential-gcloud -> /path/to/google-cloud-sdk/bin/docker-credential-gcr
...
Usually, this error indicates that your $PATH variable has been clobbered by a package or program you have recently installed so that the Google Cloud SDK can't be found.
$PATH is altered by many programs when they install by altering ~/.profile, ~/.bash_profile or ~/.bashrc or their non-bash equivalents. With a bad $PATH, Google Cloud SDK is configured in docker but can't be seen as executables so we get this error. This assumes you have used the Google Cloud SDK in the past, but if gcloud is configured with your docker then you probably have. Don't reinstall gcloud or disable it, you already have it on your system and that is fine.
The solution then is to fix your $PATH, not to install anything.
echo $PATH
This should be a pretty long : delimited list of directories that your files are in. Do you see a google-cloud-sdk/bin in the string? Is the string way too short given all the trouble you've gotten into in your life on this computer? You use NVM but it is missing? Use Homebrew but it is missing? Try brew from the command line, does it work?
If the answer is "no" to any of the above, inspect the files above to see if there are any new entries at the bottom of each that might have broken things. Did you just install anything new?
Something is clobbering your $PATH and you need to figure out what that is. For me it is usually something to do with Anaconda Python via the conda init command. For you it might be nvm or something else. Figure out what it is and fix the problem. Don't start over with a new $PATH and install the same stuff over again or disable gcloud authentication.
It really seems to be something with the Homebrew Cask. I uninstalled the cask and then reinstalled the Google Cloud SDK by manually downloading the tar ball and running the packaged install script as described there.
Now docker-credential-gcloud is in my path:
$ which docker-credential-gcloud
/Users/moritz/google-cloud-sdk/bin/docker-credential-gcloud
I can't figure out what Google is trying to achieve here. On Linux there is docker-credential-gcloud and on Windows there is docker-credential-gcr.exe, and then there is docker-credential-gcloud.cmd which calls gcloud auth docker-helper. This is kind of a nightmare if you're trying to write portable build scripts or gradle rules because not everything seems capable of finding and calling docker-credential-gcloud.cmd when you exec docker-credential-gcloud... it might work from the dos prompt, but in general doesn't work.
After a ton of fooling around with .bat scripts, cygwin scripts, .cmd scripts and so forth, I found the best solution was to go into the gcloud installation and just copy docker-credential-gcr.exe docker-credential-gcloud.exe ... not a very satisfying solution, but is the only thing I found that would do the trick.
I got the issue when I tried to SSH from Google Cloud Build into an Engine VM Instance, so I had
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args: ['compute', 'ssh',
'--project', '$PROJECT_ID',
'--zone', 'asia-southeast1-b',
'--strict-host-key-checking=no',
'username#instance-1',
'--command' ,'sh start.sh'
My start.sh
#!/bin/sh
echo "Started: $(date --iso-8601=seconds)"
docker pull gcr.io/aaa/bbbc/cccc
echo "Finished: $(date --iso-8601=seconds)"
The issue was How to set PATH when running a ssh command?
https://unix.stackexchange.com/questions/332532/how-to-set-path-when-running-a-ssh-command
So I just faced the same problem where I am trying to pull an image from GCR to an GCP instance and want to share my solution.
I ran gcloud auth configure-docker and got the warning:
WARNING: `docker-credential-gcloud\` not in system PATH.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.
I applied the accepted answer for this thread and ran gcloud components install docker-credential-gcr and got a long error:
ERROR: (gcloud.components.install) You cannot perform this action because this Cloud SDK installation is managed by an external package manager.
Please consider using a separate installation of the Cloud SDK created through the default mechanism described at: https://cloud.google.com/sdk/
When no solution was working, I uninstalled the Google provided google-cloud-sdk package that was installed via snap and instlled with distro specifice package manager, for me that is apt-get as instructed in the Installing Google Cloud SDK: Installation options page and re-ran the gcloud auth configure-docker and this time it solved my problem.
In my case the problem was due to how WSL 1 works with Docker on Windows. At first I only installed and initialized gcloud in WSL Ubuntu, not in Windows. However as Docker daemon is actually run by Windows, you need to install gcloud for Windows as well (and don't forget to run all of the inits and authorizations there).
On Windows 10/11, you need to ensure that C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\ is added to your system $PATH environment variable. It may not have been added if the Google Cloud SDK was not able to add it during GCloud installation. So add it manually like this:
Windows Task Bar ➔ Press the search icon 🔍 or the search bar
Type "environment" ➔ and click on "Edit the System Environment Variables" (ensure that you have Administrator access)
At the bottom of the dialog, click the Environment Variables... button
System Variables ➔ click Path ➔ Edit... ➔ New ➔ paste in C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\ (replace "USERNAME" with your username)
Close and restart any open Command Prompt windows.
Then verify on the Git Bash for Windows console:
Optional: Note that the AppData folder is hidden by default, so you may want to unhide AppData first, to see its contents.
Restart the Git Bash Terminal window
echo $PATH ➔ This should print a long string that contains: :/c/Users/USERNAME/AppData/Local/Google/Cloud SDK/google-cloud-sdk/bin
where docker-credential-gcloud ➔ This should print C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\docker-credential-gcloud.cmd
i'm trying to get jenkins running on debian 7 but i keep getting this error while apt-get install jenkins is running.
Setting up dbus (1.6.8-1) ...
Failed to open connection to "system" message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[ ok ] Starting system message bus: dbus.
Also i get the message that jenkins is started at the end and no error message:
[ ok ] Starting Jenkins Continuous Integration Server: jenkins.
but /etc/init.d/jenkins status gives me the output that jenkins is not running. also ls -alh /var/lib/jenkins gives me an empty folder.
So the install fails with no error.
This is the way i'm running the install:
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add -
sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
apt-get update
apt-get install jenkins
Has anyone of you tried installing jenkins on a fresh debian 7?
looking forward for helping answers.
kind regards and thanks in advance
So i solved the problem finally.
I expected the Java SDK to have the right JRE in it, so i downloaded it from the Oracle website: jdk1.7.0_21-x64-linux.tar.gz after installing and registering this to my machine it worked java -version and javac -version.
Problem was the version of this JRE did not work with Jenkins so thanks to #wako, i installed openjdk-7-jre and i have now two jre's running on my machine but jenkins started finally. need to figure out if openjdk-7-jre suits my plans or if i need to fall back to Debian 6.
This is an issue with apt-get and not with Jenkins -
please make sure you run it as root.
Can try to install (or upgrade) another package, to confirm.
I had the same problem on the debian 7 freshly installed, via the light version of debian 7 with the ssh server only installed.
First I add the repository as you specified it, try to install jenkins but some dependencies were broken (daemon-psmisc-java2-runtime).
To solve the problem I did an:
apt-get -f upgrade
And it was OK
To complete the installation of jenkins you will need apache2 and java-jre
apt-get install apache2 openjdk-7-jre