{"id":33685,"date":"2024-06-16T11:10:00","date_gmt":"2024-06-16T09:10:00","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=33685"},"modified":"2024-06-16T09:59:49","modified_gmt":"2024-06-16T07:59:49","slug":"using-local-images-with-nerdctl-build","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/","title":{"rendered":"Using local images with nerdctl build?"},"content":{"rendered":"\n

Following the issue I talked about in my last blog<\/a>, I started building local images using “nerdctl” for OpenText Documentum 23.4. That worked properly for the first one, which was using the Red Hat base, to install some common OS packages used by for components\/containers of Documentum. However, when I tried to do the next one, based on it, to start installing an Oracle Client specifically for the Documentum Content Server container, it failed with this error:<\/p>\n\n\n

\nMac:ora-client$ .\/build.sh\n************************************************\n*** Building the image 'ora-client:19.3.0.0' ***\n************************************************\n\n[+] Building 2.2s (3\/3) FINISHED\n => [internal] load build definition from Dockerfile                                                             0.1s\n => => transferring dockerfile: 1.42kB                                                                           0.0s\n => [internal] load .dockerignore                                                                                0.1s\n => => transferring context: 2B                                                                                  0.0s\n => ERROR [internal] load metadata for registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901               2.1s\n------\n > [internal] load metadata for registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901:\n------\nDockerfile:12\n--------------------\n  10 |\n  11 |     ARG ARG_BASE_IMAGE\n  12 | >>> FROM $ARG_BASE_IMAGE\n  13 |\n  14 |     LABEL maintainer="dbi ECM & Application Integration <dbi_eai@dbi-services.com>"\n--------------------\nerror: failed to solve: registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901: failed to do request: Head "https:\/\/registry-sbx.it.dbi-services.com\/v2\/dbi_dctm\/linux-ot\/manifests\/8.10-901": x509: certificate is valid for ingress.local, not registry-sbx.it.dbi-services.com\nFATA[0002] no image was built\nError: exit status 1\n\nFATA[0000] failed to create a tmp single-platform image "registry-sbx.it.dbi-services.com\/dbi_dctm\/ora-client:19.3.0.0-tmp-reduced-platform": image "registry-sbx.it.dbi-services.com\/dbi_dctm\/ora-client:19.3.0.0": not found\nError: exit status 1\n\n***********************************************************\n*** Script completed for 'dbi_dctm\/ora-client:19.3.0.0' ***\n***********************************************************\nMac:ora-client$\n<\/pre><\/div>\n\n\n
The above “nerdctl build” command fails on the “FROM $ARG_BASE_IMAGE<\/em>” where the base image is obviously the one I just built a few minutes before. The error is the same as for the previous blog, related to the Self-Signed SSL Certificate of the private registry. Maybe adding the “insecure-registry” parameter to the “nerdctl build” command could help workaround the security checks (Note: I tested for the sake of completeness, but it’s not possible). However, I didn’t do that in my previous blog as for me, it should only be required if you really\/absolutely need to talk to the private registry\u2026 Since I just built the base image locally, why the hell would it need to be re-downloaded? That doesn’t make a lot of sense\u2026<\/p>\n\n\n\n
Just to confirm, I checked the local images, to make sure it’s tagged properly and available:<\/p>\n\n\n
\nMac:ora-client$ nerdctl images\nREPOSITORY                                            TAG         IMAGE ID        CREATED          PLATFORM       SIZE       BLOB SIZE\nregistry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot    8.10-901    9b9b6662b7a7    9 minutes ago    linux\/amd64    1.2 GiB    347.6 MiB\nMac:ora-client$\n<\/pre><\/div>\n\n\n
So, it is indeed there. I looked at Google again and found several people saying that “nerdctl” isn’t able to use local images at all\u2026 However, I also saw some people talking about a “buildkit” namespace and I remembered seeing the namespace being “default” on my system information:<\/p>\n\n\n
\nMac:ora-client$ nerdctl system info\nClient:\n Namespace:\tdefault\n Debug Mode:\tfalse\n\nServer:\n ...\nMac:ora-client$\nMac:ora-client$ nerdctl version\nClient:\n Version:\tv1.7.3\n OS\/Arch:\tlinux\/amd64\n Git commit:\t0a464409d0178e16d3d2bed36222937ec3fc9c77\n buildctl:\n  Version:\tv0.12.5\n  GitCommit:\tbac3f2b673f3f9d33e79046008e7a38e856b3dc6\n\nServer:\n containerd:\n  Version:\tv1.7.10\n  GitCommit:\t4e1fe7492b9df85914c389d1f15a3ceedbb280ac\n runc:\n  Version:\t1.1.10\n  GitCommit:\t18a0cb0f32bcac2ecc9a10f327d282759c144dab\nMac:ora-client$\n<\/pre><\/div>\n\n\n
Therefore, I thought I could try to list the images while specifying all namespaces to see what the outcome would be. Since I had no idea about which namespaces were present, I looked at the help of “nerdctl” and saw only “moby”, “k8s.io” and “default”. No mention of “buildkit” but I still tried it anyway to see if it would throw an error:<\/p>\n\n\n
\nMac:ora-client$ nerdctl --help | grep -i namespace\n  namespace  Manage containerd namespaces\n  -n, --n string                 Alias of --namespace (default "default")\n      --namespace string         containerd namespace, such as "moby" for Docker, "k8s.io" for Kubernetes [$CONTAINERD_NAMESPACE] (default "default")\nMac:ora-client$\nMac:ora-client$ nerdctl --namespace moby image ls\nREPOSITORY    TAG    IMAGE ID    CREATED    PLATFORM    SIZE    BLOB SIZE\nMac:ora-client$\nMac:ora-client$ nerdctl --namespace k8s.io image ls\nREPOSITORY    TAG    IMAGE ID    CREATED    PLATFORM    SIZE    BLOB SIZE\nMac:ora-client$\nMac:ora-client$ nerdctl --namespace default images\nREPOSITORY                                            TAG         IMAGE ID        CREATED           PLATFORM       SIZE       BLOB SIZE\nregistry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot    8.10-901    9b9b6662b7a7    18 minutes ago    linux\/amd64    1.2 GiB    347.6 MiB\nMac:ora-client$\nMac:ora-client$ nerdctl --namespace buildkit image ls\nREPOSITORY    TAG    IMAGE ID    CREATED    PLATFORM    SIZE    BLOB SIZE\nMac:ora-client$\n<\/pre><\/div>\n\n\n
What I got from that output is that the image is currently only visible on the default namespace, I assume because I didn’t specify any in the build command. What would happen if I put that image into the “buildkit” namespace instead? I saw on the Rancher Desktop documentation<\/a> that it is possible to move an image to another environment or container engine, so I tried to execute that between namespaces:<\/p>\n\n\n
\nMac:ora-client$ nerdctl --namespace default save -o image.tar registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901\nMac:ora-client$\nMac:ora-client$ nerdctl --namespace buildkit image ls\nREPOSITORY    TAG    IMAGE ID    CREATED    PLATFORM    SIZE    BLOB SIZE\nMac:ora-client$\nMac:ora-client$ nerdctl --namespace buildkit load -i image.tar\nunpacking registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901 (sha256:9b9b6662b7a790c39882f8b4fd22e2b85bd4c419b6f6ffd350e447c35b2650f7)...\nLoaded image: registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901\nMac:ora-client$\nMac:ora-client$ nerdctl --namespace buildkit image ls\nREPOSITORY                                            TAG         IMAGE ID        CREATED           PLATFORM       SIZE       BLOB SIZE\nregistry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot    8.10-901    9b9b6662b7a7    21 seconds ago    linux\/amd64    1.2 GiB    347.6 MiB\nMac:ora-client$\nMac:ora-client$ rm image.tar\nMac:ora-client$\n<\/pre><\/div>\n\n\n
Now that the image is showing up on the “buildkit” namespace, would the build work? I simply re-executed the exact same command as before and this time it was successful:<\/p>\n\n\n
\n[+] Building 149.2s (8\/8) FINISHED\n => [internal] load build definition from Dockerfile                                                             0.1s\n => => transferring dockerfile: 1.42kB                                                                           0.0s\n => [internal] load .dockerignore                                                                                0.1s\n => => transferring context: 2B                                                                                  0.0s\n => [internal] load metadata for registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901                     4.2s\n => [internal] load build context                                                                                0.4s\n => => transferring context: 21.51kB                                                                             0.4s\n => [1\/3] FROM registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901@sha256:9b9b6662b7a790c39882f8b4fd2    4.2s\n => => resolve registry-sbx.it.dbi-services.com\/dbi_dctm\/linux-ot:8.10-901@sha256:9b9b6662b7a790c39882f8b4fd2    4.2s\n...\n => => exporting layers                                                                                          0.3s\n => => exporting manifest sha256:d6fc394f3c144735900f521d3dc603ef1b890e3460d4b94d226f9395de7ad1f3                0.1s\n => => exporting config sha256:67a60b84eacc425311471cd18fb538419e71cb1e1f4245fa21ad2215b93939f4                  0.0s\n => => sending tarball                                                                                          28.5s\n<\/pre><\/div>\n\n\n
However, the newly created image showed up on the “default” namespace. Therefore, I proceeded to add the command line parameter “–namespace buildkit” to both my “nerdctl build” and “nerdctl push” commands, so that it would create the images into the “buildkit” namespace and use these images to push them into the private registry. That way, it can use the local images and not download anything. Therefore, the updated and final commands for this second image build looks like this:<\/p>\n\n\n
\nnerdctl --namespace buildkit build --no-cache --rm \\\n  --tag="${REGISTRY}\/${OWNER}\/${NAME}" \\\n  --build-arg ARG_BASE_IMAGE="${REGISTRY}\/${OWNER}\/${BASE_IMAGE}" \\\n  --build-arg ARG_ARTIFACTORY_URL="${ARTIFACTORY_URL}" \\\n  --build-arg ARG_ORACLE_VERSION="${ORACLE_VERSION}" \\\n  --build-arg ARG_ORACLE_VERSION_DIR="${ORACLE_VERSION_DIR}" \\\n  --build-arg ARG_ORACLE_PACKAGE_1="${ORACLE_PACKAGE_1}" \\\n  --build-arg ARG_ORACLE_PACKAGE_2="${ORACLE_PACKAGE_2}" \\\n  --build-arg ARG_ORACLE_BASE="${ORACLE_BASE}" \\\n  --build-arg ARG_APP_OWNER="${APP_OWNER}" \\\n  --build-arg ARG_DATA_BASE="${DATA_BASE}" .\necho\nnerdctl --namespace buildkit push --insecure-registry ${REGISTRY}\/${OWNER}\/${NAME}\n<\/pre><\/div>\n\n\n
Just to make sure everything worked, I removed all local images and re-built the 1st and 2nd images from scratch. It behaved as expected, putting new images into the “buildkit” namespace and using them properly, without pulling anything from the private registry.<\/p>\n\n\n\n
In conclusion, is it possible to make “nerdctl” use local images? I would say yes\u2026 But you have to specifically build your images into the “buildkit” namespace and not into the “default” one, otherwise it will not work. Why? No idea :D\u2026 As an additional note, this worked on my Mac using Rancher Desktop (with both old (1.9) and recent versions (1.13)) but when I tried it on a standard Linux VM without Rancher Desktop (just pure containerd\/nerdctl), it didn’t work and was still trying to pull images from the registry, no matter what. Therefore, on the Linux VM, I switched to “podman” (yet another one\u2026 :D).<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Following the issue I talked about in my last blog, I started building local images using “nerdctl” for OpenText Documentum 23.4. That worked properly for the first one, which was using the Red Hat base, to install some common OS packages used by for components\/containers of Documentum. However, when I tried to do the next […]<\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1320],"tags":[3388,3389,3386,738],"type_dbi":[],"class_list":["post-33685","post","type-post","status-publish","format-standard","hentry","category-devops","tag-build","tag-image","tag-nerdctl","tag-registry"],"acf":[],"yoast_head":"\nUsing local images with nerdctl build? - dbi Blog<\/title>\n<meta name=\"description\" content=\"Is the nerdctl build command able to use local images that are available, instead of pulling them from the registry?\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Using local images with nerdctl build?\" \/>\n<meta property=\"og:description\" content=\"Is the nerdctl build command able to use local images that are available, instead of pulling them from the registry?\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2024-06-16T09:10:00+00:00\" \/>\n<meta name=\"author\" content=\"Morgan Patou\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@MorganPatou\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Morgan Patou\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"3 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/\"},\"author\":{\"name\":\"Morgan Patou\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"headline\":\"Using local images with nerdctl build?\",\"datePublished\":\"2024-06-16T09:10:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/\"},\"wordCount\":674,\"commentCount\":0,\"keywords\":[\"build\",\"image\",\"nerdctl\",\"Registry\"],\"articleSection\":[\"DevOps\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/\",\"name\":\"Using local images with nerdctl build? - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2024-06-16T09:10:00+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"description\":\"Is the nerdctl build command able to use local images that are available, instead of pulling them from the registry?\",\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Using local images with nerdctl build?\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8\",\"name\":\"Morgan Patou\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"caption\":\"Morgan Patou\"},\"description\":\"Morgan Patou has over 12 years of experience in Enterprise Content Management (ECM) systems, with a strong focus in recent years on platforms such as Alfresco, Documentum, and M-Files. He specializes in the architecture, setup, customization, and maintenance of ECM infrastructures in complex & critical environments. Morgan is well-versed in both engineering and operations aspects, including high availability design, system integration, and lifecycle management. He also has a solid foundation in open-source and proprietary technologies - ranging from Apache, OpenLDAP or Kerberos to enterprise-grade systems like WebLogic. Morgan Patou holds an Engineering Degree in Computer Science from ENSISA (\u00c9cole Nationale Sup\u00e9rieure d'Ing\u00e9nieurs Sud Alsace) in Mulhouse, France. He is Alfresco Content Services Certified Administrator (ACSCA), Alfresco Content Services Certified Engineer (ACSCE) as well as OpenText Documentum Certified Administrator. His industry experience spans the Public Sector, IT Services, Financial Services\/Banking, and the Pharmaceutical industry.\",\"sameAs\":[\"https:\/\/blog.dbi-services.com\/author\/morgan-patou\/\",\"https:\/\/x.com\/MorganPatou\"],\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/morgan-patou\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Using local images with nerdctl build? - dbi Blog","description":"Is the nerdctl build command able to use local images that are available, instead of pulling them from the registry?","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/","og_locale":"en_US","og_type":"article","og_title":"Using local images with nerdctl build?","og_description":"Is the nerdctl build command able to use local images that are available, instead of pulling them from the registry?","og_url":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/","og_site_name":"dbi Blog","article_published_time":"2024-06-16T09:10:00+00:00","author":"Morgan Patou","twitter_card":"summary_large_image","twitter_creator":"@MorganPatou","twitter_misc":{"Written by":"Morgan Patou","Est. reading time":"3 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/"},"author":{"name":"Morgan Patou","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"headline":"Using local images with nerdctl build?","datePublished":"2024-06-16T09:10:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/"},"wordCount":674,"commentCount":0,"keywords":["build","image","nerdctl","Registry"],"articleSection":["DevOps"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/","url":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/","name":"Using local images with nerdctl build? - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2024-06-16T09:10:00+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"description":"Is the nerdctl build command able to use local images that are available, instead of pulling them from the registry?","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/using-local-images-with-nerdctl-build\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Using local images with nerdctl build?"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8","name":"Morgan Patou","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","caption":"Morgan Patou"},"description":"Morgan Patou has over 12 years of experience in Enterprise Content Management (ECM) systems, with a strong focus in recent years on platforms such as Alfresco, Documentum, and M-Files. He specializes in the architecture, setup, customization, and maintenance of ECM infrastructures in complex & critical environments. Morgan is well-versed in both engineering and operations aspects, including high availability design, system integration, and lifecycle management. He also has a solid foundation in open-source and proprietary technologies - ranging from Apache, OpenLDAP or Kerberos to enterprise-grade systems like WebLogic. Morgan Patou holds an Engineering Degree in Computer Science from ENSISA (\u00c9cole Nationale Sup\u00e9rieure d'Ing\u00e9nieurs Sud Alsace) in Mulhouse, France. He is Alfresco Content Services Certified Administrator (ACSCA), Alfresco Content Services Certified Engineer (ACSCE) as well as OpenText Documentum Certified Administrator. His industry experience spans the Public Sector, IT Services, Financial Services\/Banking, and the Pharmaceutical industry.","sameAs":["https:\/\/blog.dbi-services.com\/author\/morgan-patou\/","https:\/\/x.com\/MorganPatou"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/morgan-patou\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/33685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=33685"}],"version-history":[{"count":2,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/33685\/revisions"}],"predecessor-version":[{"id":33687,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/33685\/revisions\/33687"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=33685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=33685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=33685"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=33685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}