[ckan-dev] Docker

Fri Oct 9 19:43:41 UTC 2015

Yes, that and some tests to keep it working.

On Fri, Oct 9, 2015 at 3:17 PM, Serban Teodorescu
<teodorescu.serban at gmail.com> wrote:
> So actually all you need is a docker-compose.yml file, maybe a template of
> that supporting some env vars. :)
>
>
>
> În Vin, 9 oct. 2015 la 18:16, Denis Zgonjanin <deniszgonjanin at gmail.com> a
> scris:
>>
>> 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
>