+1 Chamila for both #1 and #2.
Thanks
Cyril
Le 4 déc. 2017 7:42 AM, "Chamila De Alwis" a écrit :
IMO image size can be a concern, especially with C4 servers. Users who are
used to work with image sizes around 500-600MB would be in for a surprise
if we rack up an image to a
IMO image size can be a concern, especially with C4 servers. Users who are
used to work with image sizes around 500-600MB would be in for a surprise
if we rack up an image to a size about 1.5-2GB. Though what Dilan says is
true, that the ease of the process would need to be prioritized, the size
Hi Folks,
IMO, docker image size is not a major issue nowadays unless you are
extremely worrying about the image pull time and docker registry disk space
of your deployment.
What matters most here is the amount of ease of docker image build and
customization experience that we are hoping to
Hi Chamila,
Yes, we would need to make our Docker (and any other) artifacts follow the
industry accepted standards so that it is easy for users to adopt them.
More complexity means user probably will be discouraged to use our stuff.
As you mentioned, the --squash option is a good way to reduce
Hi Amila,
+1 !
We totally agree to this.
We at EMOXA have been creating our own docker files for Apim for a few time
now to avoid the initial complexity of existing wso2 generic docker/script
files.
This would be a real plus and would allow to be closer to the docker spirit
and thus allowing
Hi Chamila,
Agree with the issues you have pointed out. We have already taken these
considerations into account when doing the docker images for
Kubernetes/Openshift. You can find a sample in [1].
Also, we have used --squash flag [2] when building the docker image and it
helped us to reduce the
Hi Chamila,
+1 for this approach. This is structure has already been followed when
creating API manager docker images for kubernetes [1].
Config maps are used to add the configurations required. This only works
for kubernetes/openshift.
Are you proposing to build the docker image with the
Hi,
So far, the approach for writing Dockerfiles for WSO2 products has been to
write a generic Dockerfile that can be manipulated to build different
images with different approaches. For example, to generalize the way in
which the product is configured inside the image during build time, a