[ckan-dev] Docker

Adrià Mercader adria.mercader at okfn.org
Fri Oct 9 13:27:50 UTC 2015


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
>



More information about the ckan-dev mailing list