Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files from base not propagated to output container #1627

Closed
mlbiam opened this issue Apr 14, 2019 · 9 comments · Fixed by #1633
Closed

Files from base not propagated to output container #1627

mlbiam opened this issue Apr 14, 2019 · 9 comments · Fixed by #1633
Assignees

Comments

@mlbiam
Copy link

mlbiam commented Apr 14, 2019

Description of the issue:

Running mvn compile jib:dockerBuild on https://github.com/TremoloSecurity/OpenUnison/blob/1.0.17/unison/myvirtualdirectory-server/pom.xml generates an image missing /licenses/LICENSE and /usr/local/myvd/bin/run_myvd.sh even though both files exist in the original base image. Whats really odd is that when the base image is built off of ubuntu this works great, but when it's built off of red hat's universal base image it doesn't work.

Expected behavior:

both files should be present

Steps to reproduce:

Does NOT Work:

$ git clone https://github.com/TremoloSecurity/OpenUnison.git
$ cd OpenUnison
$ git checkout 1.0.17
$ cd unison/myvirtualdirectory-server/
$ export OU_CONTAINER_SOURCE=quay.io/tremolosecurity/myvirtualdirectory-base:latest
$ export OU_CONTAINER_DEST=docker.io/mlbiam/myvdtest
$ mvn package
$ mvn compile jib:dockerBuild
$ docker run -ti --entrypoint 'bash' docker.io/mlbiam/myvdtest
bash-4.2$ ls /usr/local/myvd/bin/
bash-4.2$

Works:

$ export OU_CONTAINER_SOURCE=tremolosecurity/myvd-jib-builder:latest
$ docker run -ti --entrypoint 'bash' docker.io/mlbiam/myvdtest
$ myvd@95b829523ccb:/$ ls /usr/local/myvd/bin/
run_myvd.sh
myvd@95b829523ccb:/$ 

Environment:

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.2", arch: "x86_64", family: "mac"

jib-maven-plugin Configuration:

<!--
    Copyright 2019 Tremolo Security, Inc.
   
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at
   
        http://www.apache.org/licenses/LICENSE-2.0
   
    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
 -->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.tremolosecurity.unison</groupId>
    <artifactId>unison</artifactId>
    <version>1.0.17</version>
  </parent>
  <artifactId>myvirtualdirectory-server</artifactId>
  <name>myvirtualdirectory-server</name>
  <dependencies>
  <dependency>
  		<groupId>com.tremolosecurity.unison</groupId>
  		<artifactId>openunison-util-classes</artifactId>
  		<version>${openunison.version}</version>
  	</dependency>
  	<dependency>
  		<groupId>com.tremolosecurity.unison</groupId>
  		<artifactId>unison-server-core</artifactId>
  		<version>${openunison.version}</version>
  	</dependency>
  	<dependency>
			<groupId>org.yaml</groupId>
			<artifactId>snakeyaml</artifactId>
			<version>${snakeyaml.version}</version>
		</dependency>
		<dependency>
			<groupId>com.googlecode.json-simple</groupId>
			<artifactId>json-simple</artifactId>
			<version>${json-simple.version}</version>
		</dependency>
		<dependency>
			<groupId>com.tremolosecurity.myvd</groupId>
			<artifactId>apacheds-service</artifactId>
			<version>2.0.0-M20</version>
		</dependency>
  </dependencies>
  
  <build>
		<plugins>
			<plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>1.0.2</version>
        <configuration>
          <from>
            <image>${env.OU_CONTAINER_SOURCE}</image>
            <auth>
              <username>${env.OU_SRC_REG_USER}</username>
              <password>${env.OU_SRC_REG_PASSWORD}</password>
            </auth> 
          </from> 
          <container>
            <user>431</user>
            <appRoot>/usr/local/myvd</appRoot>
            <entrypoint>/usr/local/myvd/bin/run_myvd.sh</entrypoint>
            <labels>
            	<name>MyVirtualDirectory</name>
            	<vendor>Tremolo Security, Inc.</vendor>
            	<version>1.0.6</version>
            	<release>latest</release>
            	<url>https://www.tremolosecurity.com/myvirtualdirectory/</url>
            	<summary>MyVirtualDirectory standard image.  You can use this image if you do not need any custom classes</summary>
            	<description>MyVirtualDirectory is an LDAP virtual directory and LDAP proxy</description>
            	<run>docker run -v /etc/myvd:/path/to/myvdsecrets -v /etc/myvd-config:/path/to/configs image</run>
            	<io.k8s.description>MyVirtualDirectory</io.k8s.description>
            	<io.k8s.display-name>MyVirtualDirectory</io.k8s.display-name>
            	<io.openshift.expose-services>10389:10636</io.openshift.expose-services>
            	<io.openshift.tags>ldap,virtual directory,identity management</io.openshift.tags>
            </labels>
          </container>
          <to>
            <image>${env.OU_CONTAINER_DEST}</image>
            <auth>
              <username>${env.OU_REG_USER}</username>
              <password>${env.OU_REG_PASSWORD}</password>
            </auth> 
            
          </to> 
        </configuration>
      </plugin>
        </plugins>
	</build>
</project>
@chanseokoh
Copy link
Member

Hi @mlbiam,

This just sounds like the base image quay.io/tremolosecurity/myvirtualdirectory-base:latest doesn't simply have those files. Can you post the output of the following commands? (Note Jib isn't involved at all.)

$ docker run -ti --entrypoint 'bash' quay.io/tremolosecurity/myvirtualdirectory-base:latest
bash-4.2$ ls /usr/local/myvd/bin/

If the base does have the files, is it possible for us to download and examine quay.io/tremolosecurity/myvirtualdirectory-base:latest?

@mlbiam
Copy link
Author

mlbiam commented Apr 15, 2019

The files are there:

mlb$ docker run -ti --entrypoint 'bash' quay.io/tremolosecurity/myvirtualdirectory-base:latest
bash-4.2$ ls /licenses/
LICENSE
bash-4.2$ ls /usr/local/myvd/bin/
run_myvd.sh

If the base does have the files, is it possible for us to download and examine quay.io/tremolosecurity/myvirtualdirectory-base:latest

Yes, it's a public repo

@chanseokoh
Copy link
Member

chanseokoh commented Apr 15, 2019

The auth was a stale creds issue, sorry.

Quay is still using the old manifest schema (Docker Image Manifest Version 2, Schema 1). Something seems not right when dealing with V2.1. I've checked that if you push the image to Docker Hub with V2.2, it works fine. For example,

$ docker tag quay.io/tremolosecurity/myvirtualdirectory-base tremolosecurity/myvirtualdirectory-base
$ docker push tremolosecurity/myvirtualdirectory-base

and then using tremolosecurity/myvirtualdirectory-base as a base image works.

@GoogleContainerTools GoogleContainerTools deleted a comment from mlbiam Apr 15, 2019
@mlbiam
Copy link
Author

mlbiam commented Apr 15, 2019

ugh. thought i had the workaround using skopeo to push the image but now i have an issue with pull too because of the old schem? Thats disappointing. Could I use skopeo to copy the container from the registry to a local tarball and have jib pull from that tarball instead? (I know, i'm reaching). I guess i can copy from the registry to dockerhub then use that as the base.

Thanks for tracking that down!

@chanseokoh chanseokoh self-assigned this Apr 15, 2019
@chanseokoh
Copy link
Member

I've got to the bottom of it. A V2.1 manifest JSON lists layers in reverse order. The V2.2 doc says

layers array

The layer list is ordered starting from the base image (opposite order of schema1).

So in V2.1 manifest, the first layer in the fsLayers list should be the most recent layer. This is a critical bug although should be trivial to fix.

@chanseokoh
Copy link
Member

@mlbiam Jib was at fault here adding layers in reverse order. #1633 will fix this. Thanks for reporting the bug.

@mlbiam
Copy link
Author

mlbiam commented Apr 16, 2019

awesome and thanks!

@chanseokoh
Copy link
Member

@mlbiam we released 1.1.1, which should fix this.

@mlbiam
Copy link
Author

mlbiam commented Apr 17, 2019

confirmed, thanks for the quick fix (and great project)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants