MY THOUGHTS ABOUT...

Filter Docker Images List by Name

How to use Docker filter parameters

I recently started exploring Docker’s possibilities. I work a lot with Sitecore and the Sitecore community is setting up all kinds of different topologies from the Sitecore Experience Platform and converting Sitecore Experience Commerce to Docker configuration. The repository can be found at GitHub: https://github.com/Sitecore/docker-images.

Based on this repository a colleague of mine created a registry Azure and created all the images according to the definitions in this repository. With this repository it’s now super easy for me to start up a certain topology of Sitecore.

However, when creating the images something went wrong the first time. I therefore received an error message at the Sitecore Experience Commerce which prevented the containers from starting. After the images had been rebuilt, I wanted to start working with these fresh images. To do that, I wanted to discard all downloaded images from that specific topology and save the rest.

My first approach was to use a combination of Powershell and Docker commands. This function works fine:

docker images | Select-String -Pattern ".*-xc-.*"

However, the output is not a list of objects that can be manipulated and at the time I wanted to combine this commado with image deletion:

docker rmi $(docker images | Select-String -Pattern ".*-xc-.*")

I got the error message:

Error response from daemon: invalid reference format: repository name must be lowercase

So the combination of PowerShell syntax and Docker didn’t seem to work.

When reading the Docker documentation a bit better I noticed that there is a filter possibility for the images you want to show. However it took some time before I understood how syntax works. I missed the “reference” option.

My first attempt was:

docker images --filter=repository="*-xc-*"

Then I discovered the reference option. However, this didn’t work:

docker images --filter=reference="*-xc-*"

After a number of attempts, I understood that the following would work:

docker images --filter=reference="*/*-xc-*:*"

You have to include the registry and the name of the image and the tag as in your pattern separated by the slash (/) and colon (:)

Now it was easy to remove all images with a certain pattern:

docker rmi $(docker images --filter=reference="*/*-xc-*:*")

Information Architecture in a Helix Era – Part 4 – Media access in foundation and feature modules

This blog post is a part of a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How we do it”, and gives our view about the setup of a flexible information architecture that can be reused in multiple projects.

Within a previous posts I introduced a Content module. This module contains fields that are used in pages. The definition of the content module is:

Name	Base templates	Fields
IContent	Standard template	–
_ContentTitle	Standard template, IContent	ContentTitle
_ContentAbstract	Standard template, IContent	ContentAbstract
_ContentImage	Standard template, IContent	ContentImage

Pages that are constructed in the project scope, inherit one or more of the _ContentTitle, _ContentAbstract and _ContentImage templates. When we focus on the _ContentImage template, containing a Sitecore image field type, we are confronted with an interesting challenge. The Source value for the image field type has to be set to a certain value from where the editors can select images. Because images are most likely project or even site scoped we have to find a way that images from other projects or sites are not accessible in the image selector.

Information Architecture in a Helix Era – Part 3 – Outline of the settings type template and content structure

This blog post is a part of a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How we do it”, and gives our view about the setup of a flexible information architecture that can be reused in multiple projects.

In the previous post we’ve given an explanation how interface templates in a module are defined and how a page and a datasource template can be constructed from the flexible nature of the interface templates. The table below gives a list of template types that are defined in the Helix architecture:

Information Architecture in a Helix Era – Part 2 – Outline of the module interface templates

This blog post is part of a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How we do it”, and gives a view about the setup of a flexible information architecture that can be reused in multiple projects.

In the previous post about this subject, a high-level overview of an information architecture in the Helix context was given. It introduced a granular definition of features. In this post I like to give a more detailed explanation about the setup of the interface templates

Template types

The Helix architecture document gives a set logical template types:

Information Architecture in a Helix Era – Introduction – Initial thoughts about the granularity of the information architecture

This blog post is the first in a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How I dit it”, and gives a view about the setup of a flexible information architecture that can be reused in multiple projects.

In 2016, Sitecore introduced a Helix, a document containing the overall design principles applied to a Sitecore project (http://helix.sitecore.net/). Besides this, a demonstration implementation of Sitecore was released, named Habitat (https://github.com/Sitecore/Habitat).

The Helix document covers all aspects of a Sitecore implementation, from Visual Studio project structure to Template definitions, to Rendering implementation. At the time Helix was introduced, I had just set up our own implementation that has similarities with Helix and Habitat: including the separation between foundation, features and projects. However, the solution setup, with the differentiating of the modules in separate projects was a great eye-opener.