[ckan-dev] Docker

[Serban Teodorescu]

Sometime this week or the next, I will provide all resources required to
build images and the docker-compose file.
You will most likely want to have a separate repo on github for Dockerfiles
and enable automated builds on docker hub.
More details to follow soon, sorry for delaying. :(

Lun, 12 oct. 2015, 13:20, Matthew Fullerton <matt.fullerton at gmail.com> a
scris:

> But I got the impression that the ckan-solr image is not in sync with the
> main repo, as when its built from the repo it works and when its pulled
> from docker hub it doesn't?
>
> It is possible to set up docker hub to do new builds every time the repo
> changes. Unfortunately that only gets us auto build for the ckan image and
> not the others as they are in sub folders. And testing is limited to
> whether it builds or not, I assume more is needed than that?
>
> -Matt
>
> On 12 October 2015 at 10:01, Adrià Mercader <adria.mercader at okfn.org>
> wrote:
>
>> Fantastic!
>>
>> Just to be clear I was talking about the docker images currently
>> hosted on the Docker Hub (the ones on the main repo)
>>
>> On 9 October 2015 at 16:16, Denis Zgonjanin <deniszgonjanin at gmail.com>
>> wrote:
>> > All of the images here are open source, generic, support multiple CKAN
>> > versions, and are tested continuously with Circle CI:
>> > https://github.com/datacats/datacats/tree/master/docker. They are also
>> used
>> > heavily in development and production.
>> >
>> > There's nothing in those images tied to datacats, so they can be used
>> with
>> > docker-compose. As Ian mentioned, if we can reconcile the images in CKAN
>> > itself with those in datacats, then you'll get both #1 and #2 for free.
>> >
>> > On Fri, Oct 9, 2015 at 9:27 AM, Adrià Mercader <adria.mercader at okfn.org
>> >
>> > wrote:
>> >>
>> >> This is probably me remembering things badly but IIRC there were three
>> >> docker images shipped with core, one for postgres, one for solr and
>> >> the main ckan one that could be extended if needed. The db and solr
>> >> ones were run previously and could be linked to the main ckan one. Or
>> >> you could not used them at all and pass the sqlalchemy.url or solr_url
>> >> settings via env var.
>> >>
>> >> This does sound like the right approach (it looks like what datacats
>> >> is doing) but if docker-compose helps make things easier then by all
>> >> means let's go for it.
>> >>
>> >> The big issue here is that
>> >>
>> >> 1. None of the core team members organizations (or any other
>> >> organization) is actually using the core Docker images (we use
>> >> dockerfiles tailored to our cloud infrastructure at OK)
>> >>
>> >> 2. The Docker images are not automatically tested.
>> >>
>> >> I think that 1 is not that important (or that it will be more likely
>> >> when 2 is in place), but the real problem IMO is that we are shipping
>> >> something on core which is not actually tested continuously as the
>> >> rest of the code. If we go ahead with providing a generic Docker
>> >> option (and I think we definitely should) then we should look into
>> >> running some basic tests to make sure they build and run fine.
>> >>
>> >> Adrià
>> >>
>> >> On 9 October 2015 at 13:50, Serban Teodorescu
>> >> <teodorescu.serban at gmail.com> wrote:
>> >> > Docker-compose is definitely the way to go.
>> >> > This can also make easier to share schema.xml with solr.
>> >> >
>> >> >
>> >> > Vin, 9 oct. 2015, 15:29, Matthew Fullerton <matt.fullerton at gmail.com>
>> a
>> >> > scris:
>> >> >>
>> >> >> The problem as I see it is linking together multiple Docker
>> containers
>> >> >> without docker compose is really painful, mainly because you can't
>> >> >> depend on
>> >> >> the internal IP addresses staying the same. Maybe there is a way to
>> >> >> overcome
>> >> >> this, but my understanding is that its that problem that docker
>> compose
>> >> >> overcomes. This was the approach Clement was taking with the
>> separate
>> >> >> repository.
>> >> >>
>> >> >> So yes, a standalone Docker that works would be useful for some
>> cases
>> >> >> and
>> >> >> maybe OK to include, but it should come attached with a warning
>> that it
>> >> >> is
>> >> >> good when CKAN is the only part to be dockerized and that for
>> complete
>> >> >> docker setups Docker compose should be used (or datacats... or....).
>> >> >>
>> >> >> Maybe my info is totally out of date. Also there is the separate
>> issue
>> >> >> that the images on Docker hub are not being kept up to date with the
>> >> >> CKAN
>> >> >> releases. I.e. the schema.xml being wrong in the solr image.
>> >> >>
>> >> >> Actually, I see now there is already a PR for docker compose:
>> >> >> https://github.com/ckan/ckan/pull/2338
>> >> >>
>> >> >> Best,
>> >> >> Matt
>> >> >>
>> >> >> On 9 October 2015 at 14:16, Adrià Mercader <adria.mercader at okfn.org
>> >
>> >> >> wrote:
>> >> >>>
>> >> >>> I think a basic docker image included with the main repo is
>> definetely
>> >> >>> the way to go, and then if people need more advanced setups they
>> can
>> >> >>> move to other options.
>> >> >>>
>> >> >>> From what I understood the only thing that needs to be fixed on the
>> >> >>> existing images is the link to schema.xml in the Solr image. Is
>> there
>> >> >>> are another reason for replacing it entirely with a new one?
>> >> >>>
>> >> >>> On 8 October 2015 at 00:21, Steven De Costa
>> >> >>> <steven.decosta at linkdigital.com.au> wrote:
>> >> >>> > Neat, thanks everyone for being so helpful here :)
>> >> >>> >
>> >> >>> > I launched a generic CKAN at www.ckanau.org last week which is
>> based
>> >> >>> > on
>> >> >>> > the
>> >> >>> > AWS marketplace build.
>> >> >>> >
>> >> >>> > One of the things I'm keen to consider for CKAN is more tools for
>> >> >>> > integration. You might consider these as extensions integrated
>> with
>> >> >>> > a
>> >> >>> > more
>> >> >>> > developed interface for platform configuration.
>> >> >>> >
>> >> >>> > I hope to attract technology partners like Docker to directly
>> >> >>> > support
>> >> >>> > some
>> >> >>> > of the use cases that are discussed here in the CKAN dev list. As
>> >> >>> > such,
>> >> >>> > it
>> >> >>> > would be good to also seed this discussion on
>> >> >>> > https://forums.docker.com/.
>> >> >>> >
>> >> >>> > I've got a few contacts into the Docker team now and aim to grow
>> >> >>> > these
>> >> >>> > out
>> >> >>> > and align things for both projects along our development roadmap.
>> >> >>> >
>> >> >>> > Hoots!
>> >> >>> >
>> >> >>> >
>> >> >>> > On Tuesday, October 6, 2015, Serban Teodorescu
>> >> >>> > <teodorescu.serban at gmail.com>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Hello.
>> >> >>> >>
>> >> >>> >> I am part of the HDX team.
>> >> >>> >>
>> >> >>> >> HDX platform uses an internally modified ckan and we migrated to
>> >> >>> >> docker
>> >> >>> >> for more than 6 months.
>> >> >>> >>
>> >> >>> >> If anyone is interested, please reply to this message and I will
>> >> >>> >> try
>> >> >>> >> to
>> >> >>> >> make a simple docker configuration using only docker and
>> >> >>> >> docker-compose.
>> >> >>> >>
>> >> >>> >> Kind regards,
>> >> >>> >> Serban Teodorescu.
>> >> >>> >>
>> >> >>> >
>> >> >>> > _______________________________________________
>> >> >>> > ckan-dev mailing list
>> >> >>> > ckan-dev at lists.okfn.org
>> >> >>> > https://lists.okfn.org/mailman/listinfo/ckan-dev
>> >> >>> > Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>> >> >>> >
>> >> >>> _______________________________________________
>> >> >>> ckan-dev mailing list
>> >> >>> ckan-dev at lists.okfn.org
>> >> >>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>> >> >>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> ckan-dev mailing list
>> >> >> ckan-dev at lists.okfn.org
>> >> >> https://lists.okfn.org/mailman/listinfo/ckan-dev
>> >> >> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > ckan-dev mailing list
>> >> > ckan-dev at lists.okfn.org
>> >> > https://lists.okfn.org/mailman/listinfo/ckan-dev
>> >> > Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>> >> >
>> >> _______________________________________________
>> >> ckan-dev mailing list
>> >> ckan-dev at lists.okfn.org
>> >> https://lists.okfn.org/mailman/listinfo/ckan-dev
>> >> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > ckan-dev mailing list
>> > ckan-dev at lists.okfn.org
>> > https://lists.okfn.org/mailman/listinfo/ckan-dev
>> > Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>> >
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20151012/5adc5f38/attachment-0003.html>