{"id":482639,"date":"2022-08-09T09:02:19","date_gmt":"2022-08-09T06:02:19","guid":{"rendered":"https:\/\/en.buradabiliyorum.com\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/"},"modified":"2022-08-09T09:02:19","modified_gmt":"2022-08-09T06:02:19","slug":"how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines","status":"publish","type":"post","link":"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/","title":{"rendered":"#How to Use Docker Buildx Bake to Create Complex Image Build Pipelines"},"content":{"rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_84 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<label for=\"ez-toc-cssicon-toggle-item-6a299daf0f9ae\" class=\"ez-toc-cssicon-toggle-label\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #dd3333;color:#dd3333\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #dd3333;color:#dd3333\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/label><input type=\"checkbox\"  id=\"ez-toc-cssicon-toggle-item-6a299daf0f9ae\" checked aria-label=\"Toggle\" \/><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-1'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#%E2%80%9CHow_to_Use_Docker_Buildx_Bake_to_Create_Complex_Image_Build_Pipelines%E2%80%9D\" >&#8220;How to Use Docker Buildx Bake to Create Complex Image Build Pipelines&#8221;<\/a><ul class='ez-toc-list-level-2' ><li class='ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Getting_Started\" >Getting Started<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Build_Targets\" >Build Targets<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Using_Multiple_Targets\" >Using Multiple Targets<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Build_Target_Inheritance\" >Build Target Inheritance<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Using_a_Previous_Target_as_a_Base_Image\" >Using a Previous Target as a Base Image<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Overriding_Properties_of_Targets_at_Build_Time\" >Overriding Properties of Targets at Build Time<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Setting_Variables\" >Setting Variables<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/buradabiliyorum.com\/en\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/#Summary\" >Summary<\/a><\/li><\/ul><\/li><\/ul><\/nav><\/div>\n<h1><span class=\"ez-toc-section\" id=\"%E2%80%9CHow_to_Use_Docker_Buildx_Bake_to_Create_Complex_Image_Build_Pipelines%E2%80%9D\"><\/span>&#8220;How to Use Docker Buildx Bake to Create Complex Image Build Pipelines&#8221;<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<div>\n<img loading=\"lazy\" decoding=\"async\" class=\"type:primaryImage alignnone size-full wp-image-805981\" data-pagespeed-no-defer=\"\" src=\"https:\/\/www.howtogeek.com\/wp-content\/uploads\/2022\/05\/Docker-New.jpeg?width=1198&amp;trim=1,1&amp;bg-color=000&amp;pad=1,1\" alt=\"Graphic showing the Docker logo\" width=\"1600\" height=\"900\"\/><\/p>\n<p>The <code>docker buildx<\/code> command group uses BuildKit to expose advanced image build capabilities. Baked builds are a high-level feature that can be used to define automated build pipelines. They lets you produce multiple images from a single build operation.<\/p>\n<p>Baked workflows are helpful when you want to publish different variants of your images or build several linked projects in parallel. In this article we\u2019ll cover the key features of <code>docker buildx bake<\/code> and how you can use them to streamline complex builds.<\/p>\n<h2 id=\"getting-started\"><span class=\"ez-toc-section\" id=\"Getting_Started\"><\/span>Getting Started<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The <code>docker buildx bake<\/code> command executes multiple build \u201ctargets\u201d that each produce a container image. Targets run in parallel where possible to maximize performance. Targets may also directly reference predecessors to create sequential pipelines.<\/p>\n<p>Build targets can be defined using several different mechanisms including existing Docker Compose files. Buildx will automatically build all the images identified in the file.<\/p>\n<p>More advanced features are exposed when you list build targets in JSON or <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/github.com\/hashicorp\/hcl\">HCL files<\/a>. These support variables, functions, and value <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/docs.docker.com\/engine\/reference\/commandline\/buildx_bake\/#hcl-variables-and-functions\">interpolation<\/a> to customize your builds.<\/p>\n<p>The <code>buildx bake<\/code> command looks for the following files in order:<\/p>\n<ul>\n<li><code>docker-compose.yml<\/code><\/li>\n<li><code>docker-compose.yaml<\/code><\/li>\n<li><code>docker-bake.json<\/code><\/li>\n<li><code>docker-bake.override.json<\/code><\/li>\n<li><code>docker-bake.hcl<\/code><\/li>\n<li><code>docker-bake.override.hcl<\/code><\/li>\n<\/ul>\n<p>You can specify a different file with the <code>-f<\/code> command flag.<\/p>\n<h2 id=\"build-targets\"><span class=\"ez-toc-section\" id=\"Build_Targets\"><\/span>Build Targets<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Build targets encapsulate all the configuration related to your build. They include details such as<\/p>\n<ul>\n<li>the path to the Dockerfile to build<\/li>\n<li><a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/www.docker.com\/blog\/dockerfiles-now-support-multiple-build-contexts\">build context paths<\/a>, defining the content available within your Dockerfile<\/li>\n<li>tags and labels to attach to the output images<\/li>\n<li>the platforms to produce images for.<\/li>\n<\/ul>\n<p>A complete list of supported config fields is available <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/docs.docker.com\/engine\/reference\/commandline\/buildx_bake\/#file-definition\">in the documentation<\/a>. Previously you may have supplied these settings as command-line flags to <code>docker buildx build<\/code> (or even plain <code>docker build<\/code>), forcing you to remember the correct values each time. With <code>buildx bake<\/code> you can reliably use the same values by defining them in your version-controlled baked file.<\/p>\n<p>Here\u2019s a simple example of a <code>docker-bake.hcl<\/code> command that defines a single build target:<\/p>\n<pre class=\"hcl\"><code>target \"default\" {&#13;\n    dockerfile = \"<a href=\"https:\/\/buradabiliyorum.com\/en\/category\/download-scripts-themes-apps\/\" data-internallinksmanager029f6b8e52c=\"9\" title=\"Download Scripts &amp; Themes &amp; Apps\" target=\"_blank\" rel=\"noopener\">app<\/a>\/Dockerfile\"&#13;\n    contexts = {&#13;\n        app = \"app\/src\"&#13;\n        shared = \"shared-components\/src\"&#13;\n    }&#13;\n    tags = [\"my-app:latest\", \"docker.io\/my-org\/my-app:latest\"]&#13;\n}<\/code><\/pre>\n<p>Running <code>docker buildx bake<\/code> with this bake file will load the <code>app\/Dockerfile<\/code> Dockerfile from your working directory. It\u2019ll have access to the <code>app\/src<\/code> and <code>shared-components\/src<\/code> directories as build contexts. The image that\u2019s produced will be assigned two tags.<\/p>\n<p>The <code>default<\/code> target is built automatically when you run <code>docker buildx bake<\/code>. You can also define named targets that can be built on-demand:<\/p>\n<pre class=\"hcl\"><code>target \"app\" {&#13;\n    \/\/ ...&#13;\n}<\/code><\/pre>\n<pre><code>$ docker buildx bake app<\/code><\/pre>\n<h2 id=\"using-multiple-targets\"><span class=\"ez-toc-section\" id=\"Using_Multiple_Targets\"><\/span>Using Multiple Targets<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>You can build another image simultaneously by defining it as a new target inside your bake file:<\/p>\n<pre class=\"hcl\"><code>group \"default\" {&#13;\n    targets = [\"app\", \"api\"]&#13;\n}&#13;\n&#13;\ntarget \"app\" {&#13;\n    dockerfile = \"app\/Dockerfile\"&#13;\n    contexts = {&#13;\n        app = \"app\/src\"&#13;\n        shared = \"shared-components\/src\"&#13;\n    }&#13;\n    tags = [\"my-app:latest\", \"docker.io\/my-org\/my-app:latest\"]&#13;\n}&#13;\n&#13;\ntarget \"api\" {&#13;\n    dockerfile = \"api\/Dockerfile\"&#13;\n    contexts = {&#13;\n        src = \"https:\/\/www.howtogeek.com\/devops\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/api\/src\"&#13;\n    }&#13;\n    tags = [\"my-api:latest\", \"docker.io\/my-org\/my-api:latest\"]&#13;\n}<\/code><\/pre>\n<p>These images can be built simultaneously because they\u2019re nested into a group. The <code>api<\/code> and <code>app<\/code> images will be built in parallel each time you run the <code>docker buildx bake<\/code> command as the <code>default<\/code> group is automatically selected. You can use named groups similarly to the named targets example above.<\/p>\n<h2 id=\"build-target-inheritance\"><span class=\"ez-toc-section\" id=\"Build_Target_Inheritance\"><\/span>Build Target Inheritance<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Build targets can inherit from each other to reuse configuration. One scenario where this can be useful concerns images that need to be customized for different environments. You might want to add extra config files to image variants intended for development use. Here\u2019s a <code>docker-bake.hcl<\/code> that demonstrates this model:<\/p>\n<pre class=\"hcl\"><code>group \"default\" {&#13;\n    targets = [\"backend\", \"backend-dev\"]&#13;\n}&#13;\n&#13;\ntarget \"backend\" {&#13;\n    dockerfile = \"backend\/Dockerfile\"&#13;\n    contexts = {&#13;\n        src = \"https:\/\/www.howtogeek.com\/devops\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/api\/src\"&#13;\n        config = \"api\/config\"&#13;\n    }&#13;\n    tags = [\"backend:latest\"]&#13;\n}&#13;\n&#13;\ntarget \"backend-dev\" {&#13;\n    inherits = [\"backend\"]&#13;\n    contexts = {&#13;\n        config = \"api\/config-dev\"&#13;\n    }&#13;\n    tags = [\"backend:dev\"]&#13;\n}<\/code><\/pre>\n<p>The <code>backend-dev<\/code> target inherits all the properties of the <code>backend<\/code> target but overrides the <code>config<\/code> context and applies a different tag.<\/p>\n<p>You can preview the merged file structure by running the <code>bake<\/code> command with the <code>--print<\/code> flag:<\/p>\n<pre><code>$ docker buildx bake --print&#13;\n...&#13;\n    \"backend-dev\": {&#13;\n      \"context\": \".\",&#13;\n      \"contexts\": {&#13;\n        \"config\": \"api\/config-dev\",&#13;\n        \"src\": \"https:\/\/www.howtogeek.com\/devops\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/api\/src\"&#13;\n      },&#13;\n      \"dockerfile\": \"backend\/Dockerfile\",&#13;\n      \"tags\": [&#13;\n        \"backend:dev\"&#13;\n      ]&#13;\n    }&#13;\n...<\/code><\/pre>\n<h2 id=\"using-a-previous-target-as-a-base-image\"><span class=\"ez-toc-section\" id=\"Using_a_Previous_Target_as_a_Base_Image\"><\/span>Using a Previous Target as a Base Image<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Sometimes you might want a build target to use the image created by a previous target as its own base. This is an alternative to multi-stage builds that can be used when your Dockerfiles depend on each other but can\u2019t be merged together, perhaps because they exist in different projects.<\/p>\n<pre class=\"hcl\"><code>group \"default\" {&#13;\n    targets = [\"org-base-image\", \"api\"]&#13;\n}&#13;\n&#13;\ntarget \"org-base-image\" {&#13;\n    dockerfile = \"docker-base\/Dockerfile\"&#13;\n    tags = [\"org-base-image:latest\"]&#13;\n}&#13;\n&#13;\ntarget \"api\" {&#13;\n    dockerfile = \"api\/Dockerfile\"&#13;\n    contexts = {&#13;\n        base = \"target:org-base-image\"&#13;\n    }&#13;\n    tags = [\"api:latest\"]&#13;\n}<\/code><\/pre>\n<p>The example first builds the <code>org-base-image<\/code> target. This could contain some utilities that are common to your organization\u2019s containerized workloads. The <code>api<\/code> target is then built with the output from the <code>org-base-image<\/code> target accessible as the <code>base<\/code> build-context. The API Dockerfile can now reference content inside the base image:<\/p>\n<pre><code>COPY --from=base \/utilities\/example \/usr\/bin\/example-utility<\/code><\/pre>\n<p>This is a powerful pattern that lets you create dependency links between images while maintaining separate Dockerfiles.<\/p>\n<h2 id=\"overriding-target-properties-at-build-time\"><span class=\"ez-toc-section\" id=\"Overriding_Properties_of_Targets_at_Build_Time\"><\/span>Overriding Properties of Targets at Build Time<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The <code>docker buildx bake<\/code> command lets you override properties of your targets when you run your build:<\/p>\n<pre><code>$ docker buildx bake --set api.dockerfile=\"api\/Dockerfile-dev\"<\/code><\/pre>\n<p>This example changes the Dockerfile of the <code>api<\/code> target. The <code>*<\/code> wildcard is supported when identifying the target to change. <code>*<\/code> on its own selects every target while <code>api*<\/code> will modify all the targets that begin with <code>api<\/code>.<\/p>\n<h2 id=\"setting-variables\"><span class=\"ez-toc-section\" id=\"Setting_Variables\"><\/span>Setting Variables<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>HCL files can define variables that you can reference in your build targets. use a <code>variable<\/code> block to set them up:<\/p>\n<pre class=\"hcl\"><code>variable \"TAG\" {&#13;\n    default = \"latest\"&#13;\n}&#13;\n&#13;\ngroup \"default\" {&#13;\n    targets = [\"app\"]&#13;\n}&#13;\n&#13;\ntarget \"app\" {&#13;\n    dockerfile = \"src\/Dockerfile\"&#13;\n    tags = [\"my-app:${TAG}\"]&#13;\n}<\/code><\/pre>\n<p>Running <code>docker buildx bake<\/code> with this configuration will tag the <code>app<\/code> target as <code>my-app:latest<\/code>. You can change the value of the <code>TAG<\/code> variable by setting an environment variable before you execute the command:<\/p>\n<pre><code>$ TAG=v1 docker buildx bake<\/code><\/pre>\n<p>You can use all the variable interpolation and comparison capabilities of <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/github.com\/hashicorp\/hcl\">the HCL language<\/a> to make your build targets reusable. Functions <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/github.com\/docker\/buildx\/blob\/master\/bake\/hclparser\/stdlib.go\">are available too<\/a> for parsing and transforming your values.<\/p>\n<h2 id=\"conclusion\"><span class=\"ez-toc-section\" id=\"Summary\"><\/span>Summary<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Baked Buildx builds let you encapsulate image build configuration as \u201ctargets\u201d defined in a file. When you run <code>buildx bake<\/code>, images for all the referenced targets are built in parallel.<\/p>\n<p>Targets can inherit from and depend on each other. You can also use <a rel=\"nofollow noopener\" target=\"_blank\" href=\"https:\/\/docs.docker.com\/engine\/reference\/commandline\/buildx_bake\/#hcl-variables-and-functions\">variables and functions<\/a> to create highly complex and configurable build pipelines.<\/p>\n<p>The <code>docker buildx bake<\/code> command is a high-level operation that\u2019s not necessary in every workflow. You don\u2019t need to use it when you\u2019re creating simple images with no cross-project dependencies. Using <code>docker compose build<\/code> is a better alternative for most use cases that keeps build configuration in your <code>docker-compose.yml<\/code> file. Switching to baked builds should be considered when you\u2019re building many images simultaneously using different variables, platforms, build contexts, and config overrides.<\/p>\n<\/div>\n<p><script>\n setTimeout(function(){\n  !function(f,b,e,v,n,t,s)\n  {if(f.fbq)return;n=f.fbq=function(){n.callMethod?\n  n.callMethod.apply(n,arguments):n.queue.push(arguments)};\n  if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';\n  n.queue=[];t=b.createElement(e);t.async=!0;\n  t.src=v;s=b.getElementsByTagName(e)[0];\n  s.parentNode.insertBefore(t,s) } (window, document,'script',\n  'https:\/\/connect.facebook.net\/en_US\/fbevents.js');\n   fbq('init', '335401813750447');\n   fbq('track', 'PageView');\n  },3000);\n<\/script><\/p>\n<blockquote><p><strong><span style=\"color: #ff6600;\">If you liked the article, do not forget to share it with your friends. Follow us on\u00a0<span style=\"color: #ff0000;\"><a style=\"color: #ff0000;\" href=\"https:\/\/news.google.com\/publications\/CAAqBwgKMLG0nwswvr63Aw\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">Google News<\/a><\/span>\u00a0too, click on the star and choose us from your favorites.<\/span><\/strong><\/p><\/blockquote>\n<blockquote>\n<p style=\"text-align: center;\">For forums sites go to <span style=\"color: #ff9900;\"><a style=\"color: #ff9900;\" href=\"https:\/\/forum.buradabiliyorum.com\/\" target=\"_blank\" rel=\"noopener\">Forum.BuradaBiliyorum.Com<\/a><\/span><\/strong><\/p>\n<\/blockquote>\n<blockquote>\n<p style=\"text-align: center;\"><strong>If you want to read more like this article, you can visit our <span style=\"color: #ff9900;\"><a style=\"color: #ff9900;\" href=\"https:\/\/en.buradabiliyorum.com\/technology\/\" target=\"_blank\" rel=\"noopener\">Technology category.<\/a><\/span><\/strong><\/p>\n<\/blockquote>\n<p><span style=\"color: black;\"><a style=\"color: #ff9900;\" href=\"https:\/\/www.howtogeek.com\/devops\/how-to-use-docker-buildx-bake-to-create-complex-image-build-pipelines\/\" target=\"_blank\" rel=\"noopener\">Source<\/a><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>&#8220;How to Use Docker Buildx Bake to Create Complex Image Build Pipelines&#8221; The docker buildx command group uses BuildKit to expose advanced image build capabilities. Baked builds are a high-level feature that can be used to define automated build pipelines. They lets you produce multiple images from a single build operation. Baked workflows are helpful&#8230;<\/p>\n","protected":false},"author":1,"featured_media":482640,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/www.howtogeek.com\/wp-content\/uploads\/2022\/05\/Docker-New.jpeg?height=200p&trim=2,2,2,2","fifu_image_alt":"","footnotes":""},"categories":[18],"tags":[],"class_list":["post-482639","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/posts\/482639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/comments?post=482639"}],"version-history":[{"count":0,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/posts\/482639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/media\/482640"}],"wp:attachment":[{"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/media?parent=482639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/categories?post=482639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/buradabiliyorum.com\/en\/wp-json\/wp\/v2\/tags?post=482639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}