On Thu, Mar 31, 2016 at 5:23 PM, Gayan Gunarathne <[email protected]> wrote:

>
>
> On Thu, Mar 31, 2016 at 2:05 PM, Isuru Haththotuwa <[email protected]>
> wrote:
>
>> Earlier the PaaS team had a discussion in architecture list thread [1] to
>> create a base Docker image and a profile Docker image extending the base
>> Docker image per WSO2 product. This was done for the ease of the users of
>> wso2 Dockerfiles. More details can be found in the mentioned thread.
>> However, we found this approach to have a few drawbacks:
>>
>>    - The second image size would be comparatively large even if a simple
>>    config change is done. This is because docker adds an additional layer on
>>    top of existing layer, if we need to do a change to the existing layer.
>>    - The main rationale for having two images was the ease of using it;
>>    but a user/developer using a single Dockerfile can still do this manually,
>>    by extending from the existing image, for testing purposes.
>>
>> Therefore, the PaaS team had another internal discussion and decided to
>> scrap the two Dockerfile approach and use a single Dockerfile per WSO2
>> product.
>> In development phase, user/developer can either create a simple
>> Dockerfile extending a product Dockerfile, and add the config/artifact
>> changes using ADD/COPY statements [2]. When the container is starting up, a
>> script will copy the relevant artifacts to the directory structure under
>> the carbon server before actually starting the server.
>>
>
> So user need to have own set of artifacts and those artifact will be
> copied when docker image creation.So what happen in the case of the dynamic
> deployment like PaaS solution. As some configurations may dynamic, at the
> startup user may not aware of it.In that case are we generating the
> artifacts on the fly and copy to the docker image?
>
An artifact that needs to be deployed by the product should be bundled in
the image itself; IMHO apart from API Manager we can do this for all other
products, using car files, etc. For APIM, we need to figure out a proper
way to synchronize the runtime artifacts (APIs).

If there is a need to update an artifact, a new image should be built and
rolled out. We are using the immutable server concept [1] here.

[1]. http://martinfowler.com/bliki/ImmutableServer.html

>
>
>> Else, another option would be to provide a host machine directory (shared
>> volume) when starting up a container from the provided wso2 product
>> Dockerfile (without creating a separate Dockerfile). This shared location
>> can have a directory structure similar to a carbon server, which will be
>> again copied to the carbon server before starting up.
>>
>> Prior to moving in to production, the recommended way would be to
>> re-build the image with all configurations in place, using the latest
>> ubuntu base image. This final Dockerfile should have a minimum number of
>> ADD/COPY/RUN commands to reduce the image size.
>>
>> Please share your thoughts on this. PaaS team will be updating the WSO2
>> Dockerfiles repository with this structure.
>>
>> [1]. [WSO2 Docker Images] Creating Base Docker Images for WSO2 Products
>>
>> [2].
>> FROM wso2am:1.10.0
>> MAINTAINER [email protected]
>>
>> COPY artifacts/ /mnt/wso2-artifacts/carbon-home
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead, WSO2 Inc. (http://wso2.com)
> Committer & PMC Member, Apache Stratos
> email : [email protected]  | mobile : +94 775030545 <%2B94%20766819985>
>
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* <http://wso2.com/>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to