[ckan-dev] Docker

Mon Oct 12 08:01:32 UTC 2015

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
>