Hi Sajith,

There are repositories on Dockerhub without organizations, such as mysql
[1] and tomcat [2] which are official repositories. When the images are
pushed to DockerHub, the organization name can be used as "wso2".
Furthermore, the products are WSO2 prefixed (WSO2MB vs MB) so the name
should be *org_name/wso2{product_code}*.

[1] - https://hub.docker.com/_/mysql/
[2] - https://hub.docker.com/_/tomcat/


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Thu, Mar 31, 2016 at 3:25 PM, Sajith Kariyawasam <saj...@wso2.com> wrote:

> It seems the image name format we have now is wso2as:5.3.0. Shouldn't it
> be like wso2/as:5.3.0 ?
> Otherwise, once we push to dockerhub in future, we need to have separate
> user accounts for each product which is not feasible.
>
> On Thu, Mar 31, 2016 at 2:05 PM, Isuru Haththotuwa <isu...@wso2.com>
> 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.
>> 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 isu...@wso2.com
>>
>> COPY artifacts/ /mnt/wso2-artifacts/carbon-home
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
>
> --
> Sajith Kariyawasam
> *Committer and PMC member, Apache Stratos, *
> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
> *Mobile: 0772269575*
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to