container does not start properly in OpenShift
pvalena opened this issue · 11 comments
Using imagestream from PR #4:
>>> oc create -f golang-centos7-image-streams.json
>>> oc new-app golang~http://github.com/cpuguy83/go-md2man
--> Found image 8547624 (7 days old) in image stream "myproject/golang" under tag "1.8" for "golang"
Go 1.8
------
Go 1.8 available as docker container is a base platform for building and running various Go 1.8 applications and frameworks. Go is an easy to learn, powerful, statically typed language in the C/C++ tradition with garbage collection, concurrent programming support, and memory safety features.
Tags: builder, golang, golang18, rh-golang18, go
* A source build using source code from http://github.com/cpuguy83/go-md2man will be created
* The resulting image will be pushed to image stream "go-md2man:latest"
* Use 'start-build' to trigger a new build
* This image will be deployed in deployment config "go-md2man"
* The image does not expose any ports - if you want to load balance or send traffic to this component
you will need to create a service with 'expose dc/go-md2man --port=[port]' later
--> Creating resources ...
imagestream "go-md2man" created
buildconfig "go-md2man" created
deploymentconfig "go-md2man" created
--> Success
Build scheduled, use 'oc logs -f bc/go-md2man' to track its progress.
Run 'oc status' to view your app.
>>> oc logs go-md2man-1-wpmbm
/usr/libexec/s2i/run: line 5: /opt/app-root/gobinary: No such file or directory
Build and deploy went fine, the last is the resulting pod, which fails.
Could you attach the log from the build. I haven't touch the image stream topic yet, trying to reproduce it now.
@sspeiche, @pvalena One thing is, did it ever worked? Second is there any difference in the s2i build invocation when the image stream is used? It seems that just usage script is invoked(s2i without any arguments), when the md2man is being built. Is there way how to specify the build invocation it the image stream description?
In 1.8/s2i/bin/ you have assemble script, where you can define how the image will be built and run script where you specify how it'll be executed.
This is the first time I've tested it, so I do not know whether it ever worked. image stream is not related. That's just distribution mechanism (docker binding) AFAIK.
Build log:
>>> oc logs go-md2man-1-build
Cloning "http://github.com/cpuguy83/go-md2man" ...
Commit: 48d8747a2ca13185e7cc8efe6e9fc196a83f71a5 (Merge pull request #37 from kolyshkin/links)
Author: Brian Goff <cpuguy83@gmail.com>
Date: Wed Feb 14 21:17:27 2018 -0500
/tmp/src ~
This is a S2I golang-1.8 centos base image:
To use it, install S2I: https://github.com/openshift/source-to-image
Sample invocation:
s2i build -e IMPORT_URL='github.com/cpuguy83/go-md2man' git://github.com/cpuguy83/go-md2man centos/golang-1.8-centos go-sample-app
You can then run the resulting image via:
docker run go-sample-app
Pushing image 172.30.1.1:5000/test-golang/go-md2man:latest ...
Pushed 0/10 layers, 1% complete
Pushed 1/10 layers, 11% complete
Pushed 2/10 layers, 21% complete
Pushed 3/10 layers, 30% complete
Pushed 4/10 layers, 42% complete
Pushed 5/10 layers, 51% complete
Pushed 6/10 layers, 61% complete
Pushed 7/10 layers, 75% complete
Pushed 8/10 layers, 98% complete
Pushed 9/10 layers, 99% complete
Pushed 10/10 layers, 100% complete
Push successful
Let me know if you need some specific file content or command output from the build pod.
Please note that regular build in the origin without the images stream from the PR works as expected. This seems as some sort of issue with either openshift or the image stream file.
@pvalena I know I have written these. Please read the log of the build and it will be obvious that the the build image is executed, like "docker run image". One thing might be that your oc invocation creating the build is incorrect, i.e. it will chose incorrect build strategy, but I'm not origin expert.
Please note that regular build in the origin without the images stream from the PR works as expected. This seems as some sort of issue with either openshift or the image stream file.
Without the imagestream, there's no golang available from OpenShift instance on RHEL. So there has to be one created. What do you mean, specifically, by "regular build in origin"?
@pvalena I know I have written these. Please read the log of the build and it will be obvious that the the build image is executed, like "docker run image". One thing might be that your oc invocation creating the build is incorrect, i.e. it will chose incorrect build strategy, but I'm not origin expert.
Yes, I can see that.
I do not, however, execute OpenShift build in any unusal way. This is the way it should work (how s2i-build is executed from OpenShift, specifically). But maybe there's some difference in this image (or its usage) that I'm missing (other container images work fine using the same procedure).
Note that golang container is listed among those supported for oc new-app (language detection is part of it).
My env:
$ oc version
oc v3.5.5.31.19
kubernetes v1.5.2+43a9be4
features: Basic-Auth GSSAPI Kerberos SPNEGO
Server https://10.0.2.15:8443
openshift v3.5.5.31.19
kubernetes v1.5.2+43a9be4
$ grep ^VERSION= /etc/os-release
VERSION="7.5 (Maipo)"
I'm using OCP instance that oc cluster up creates.
@jcajka yes it worked, I deployed on Online Starter (3.9 pre-GA) without a hitch. You can see in the image stream that I'm using the hello-openshift simple go program as the example to build.
From a local build:
$ s2i build http://github.com/cpuguy83/go-md2man devtools/go-toolset-7-rhel7:latest testing
I0327 09:45:25.110426 09989 clone.go:32] Downloading "http://github.com/cpuguy83/go-md2man" ...
I0327 09:45:26.508399 09989 install.go:251] Using "assemble" installed from "image:///usr/libexec/s2i/assemble"
I0327 09:45:26.508425 09989 install.go:251] Using "run" installed from "image:///usr/libexec/s2i/run"
I0327 09:45:26.508437 09989 install.go:251] Using "save-artifacts" installed from "image:///usr/libexec/s2i/save-artifacts"
E0327 09:45:27.386580 09989 util.go:91] + pushd /tmp/src
/tmp/src ~
E0327 09:45:27.386877 09989 util.go:91] ++ go list -f '{{.Incomplete}}'
E0327 09:45:27.466775 09989 util.go:91] + [[ true == \t\r\u\e ]]
E0327 09:45:27.466797 09989 util.go:91] + INSTALL_URL=
E0327 09:45:27.466803 09989 util.go:91] + [[ ! -z '' ]]
E0327 09:45:27.466808 09989 util.go:91] + exec //usr/libexec/s2i/usage
This is a S2I golang-1.8 rhel base image:
To use it, install S2I: https://github.com/openshift/source-to-image
Sample invocation:
s2i build -e IMPORT_URL='github.com/cpuguy83/go-md2man' git://github.com/cpuguy83/go-md2man rhscl/golang-1.8-rhel go-sample-app
You can then run the resulting image via:
docker run go-sample-app
$ docker run --rm testing
/usr/libexec/s2i/run: line 5: /opt/app-root/gobinary: No such file or directory
With IMPORT_URL set to github.com/cpuguy83/go-md2man it works. Should not the build fail when the IMPORT_URL is needed? (know nothing about golang)
@pkubatrh @pvalena yeah, you will need to set the IMPORT_URL as the md2man have incomplete dependencies so it can't take the naive approach to the build. So there is no bug per se. Sorry for not noticing it at first, I have been looking for more insidious issue and I haven't noticed the tree thought the forest.
On unrelated note I have notice that the assemble script is incorrect for repository with complete deps and set IMPORT_URL/enabled incremental build. PR in the works.
You're right. Using other repo/app it works fine.
>>> oc create -f golang-centos7-image-streams.json
imagestream "golang" created
>>> oc new-app golang~https://github.com/tiwillia/hello-openshift-example
--> Found image 8547624 (2 weeks old) in image stream "test-golang/golang" under tag "1.8" for "golang"
[ . . . ]
>>> oc logs -f hello-openshift-example-1-12hjc
serving on 8888
serving on 8080
Thanks for help!