Empowering operators through generative AI technologies with Azure for Operators

OpenAI’s offerings—ChatGPT, Codex, Sora, and DALL-E—have caught the public’s imagination and opened doors to many opportunities for infusing AI into networks, systems, services, and applications. These cutting-edge AI technologies are now deeply integrated with Microsoft products including Bing, Windows, Office, and Microsoft Teams. Within Azure for Operators, we are taking advantage of the significant investments Microsoft has made and its expertise in programming foundation models by developing technical solutions that will give our customers a competitive advantage. Our product portfolio, which includes Azure Operator Nexus, Azure Operator Insights, and Azure private multi-access edge compute is being augmented with generative AI technologies, empowering operators to efficiently solve real-world problems. But before we get into the solutions, let’s begin with a brief background on generative AI and recent AI advancements.

Azure for Operators

Get to know the Microsoft portfolio for operators

Discover solutions

Foundation models and the next era of ai

Read the blog

Background on generative AI

OpenAI’s generative models have drawn significant attention for their exceptional performance in generating text, image, video, and code. Among these generative models, a notable breakthrough is generative pre-trained transformer (GPT), a large language model with hundreds of billions of parameters. GPT is pre-trained on a vast corpus of data from the open internet, allowing it to comprehend natural language and generate human-like responses to input prompts from users. ChatGPT, Codex (the model behind GitHub Copilot), Sora, and DALL-E are all derived from the pre-trained GPT (or foundation model). Codex is additionally trained on code from 54 million GitHub repositories—a process known as “fine-tuning.” To enable the customization of GPT for new language tasks, OpenAI offers a paid API service that allows developers to fine-tune GPT on domain-specific data through a command-line interface and query the fine-tuned model without accessing the underlying model. Through a partnership with OpenAI, Microsoft benefits from exclusive access to the underlying model and parameters of GPT, placing us in a strong position to develop inference and a fine-tuning infrastructure. 

Microsoft and openai exclusively license gpt-3

Read the blog

We have divided our AI and machine learning investments into four categories:

Reactive management:​ Automated incident management.​

Proactive management: Automated anomaly detection and fault localization.

AI and machine learning infused into Azure for Operators products​.

AI and machine learning engineering platform across Azure for Operators​.

I want to talk a little about our investments that fall under the first two categories. These systems showcase the potential of foundation models as they are incorporated into our products, and they can significantly impact the way mobile operator networks are developed, operated, and managed.

Reactive management: Data intelligence copilot for operators

Operators gather vast amounts of data, including node-level, gNodeB-level, user-level, and flow-level data, for purposes like network monitoring, performance tracking, capacity management, and debugging. In commercial operator networks, the number of such counters and metrics that are regularly computed often exceeds several thousands, accounting for tens of Gbps of data transfer. Retrieving relevant metrics and visualizing them is crucial for network operations. However, the complexity of modern wireless systems and the vast number of counters involved make this task challenging, necessitating expert knowledge to perform this essential operation.

The process today involves specialists with expert knowledge creating dashboards for a limited number of metrics, which the operators browse through to obtain relevant information. However, if operators require customized data, such as visualizing throughput for a specific user rather than aggregate throughput or if they need access to a different set of metrics for complex debugging purposes, a loop through the specialists is required. The specialists need to identify the relevant variables, write code in database query language to combine them in an appropriate manner, and then create and share a dashboard. 

Can operators interact with their data by asking simple questions in natural language, without having to remember any of the complex counter names or how to combine them in a database query language?

We believe that such a system has the potential to significantly transform the status quo. It would provide a more natural way to interact with operator data without heavy reliance on specialists. This would reduce the time to mitigate network issues, and it would provide more value from the operator data by reducing the barrier to customized insights.

The development of foundation models like GPT-4 has significantly advanced the capabilities of natural language interfaces for data interaction, demonstrating remarkable performance on standard text-to-SQL datasets. Despite these achievements, challenges persist in specialized and niche domains such as operator data. These challenges include the handling of specialized information that is often not publicly available, the overwhelming volume of data counters and metrics that exceeds the prompt size limits of these models, and the need for numerical accuracy that is crucial for decision-making in network operations but which the foundation models are not adept at.

System architecture for data intelligence copilot for operators.

We have developed data intelligence copilot for operators, a natural language interface for retrieval and analytics tasks on operator data, leveraging foundation models. It addresses the challenges posed by operator data through a combination of a domain-specific database with comprehensive metrics descriptions, a semantic search for filtering relevant metrics within the models’ prompt size limits, few-shot learning for enhancing numerical accuracy in code generation, and expert feedback mechanisms that allow for continuous improvement of the database through contributions from domain experts.1 This copilot is being integrated into our Azure Operator Insights product as a knowledge assistant.

Reactive management: Intent-based network management

Generally, operator networks are very complex with management operations, heavily relying on highly skilled professionals and sophisticated management tools to create, update, and deploy network configurations. Configuration files can be several tens of thousands of lines long. This process is not only labor-intensive but also error-prone, underscoring a need for automation to alleviate the management burden for network operators.

We have been working on a promising paradigm called intent-based networking (IBN), a solution to simplify network management for operators. It allows network operators to specify the desired behavior or “intent” of their network in natural language. They can say, “Allow ICMP traffic in my network,” and then the solution automatically translates the intent into updated network configurations. IBN can present these updated configurations to network administrators for review prior to their deployment, ensuring network safety while keeping minimal human intervention.

Intent-based networking agent powered by GPT simplifies network management.

Although the concept of IBN has been around for some time, its implementation has been hindered by the complexities of natural language understanding and the intricate task of configuration generation. Motivated by recent advances in generative AI (for example GPT), we revisited this problem and developed a tool named “IBN agent” based on GPT. Our IBN agent takes as input the running network configuration and the user’s natural language intent. It then queries GPT to update the network configuration according to the user intent. Utilizing existing configuration syntax checks and network verification tools, the IBN agent also flags errors in the GPT-generated configurations. Moreover, users can intervene at any point and provide feedback on any undesired behavior. Based on these identified errors or user feedback, the IBN agent iteratively refines the configuration with GPT until all automated and human checks are passed. We believe that IBN holds substantial potential to simplify network configuration in the future.

Proactive maintenance: Next generation communications copilot for operators

Practitioners, engineers, researchers, and students can find themselves grappling with a multitude of acronyms and intricate terminology with information spread across many documents, which makes working with and developing standards-compliant systems an onerous and time-consuming task. For example, an engineering team working on implementing a registration request procedure as a part of building 5G virtual core would need to identify all the relevant technical specifications from among thousands of documents and understand the call flow and message formats as described in those specifications.

The current method of acquiring this information involves sifting through numerous webpages and technical specification documents. While this approach provides extensive comprehension of a topic from various sources, it can also be time-intensive and tedious to identify, gather, and synthesize information from multiple relevant sources.

Foundation models represent a significant advancement in providing synthesized, readily comprehensible answers to user queries related to wireless communication specifications. However, despite the usefulness of state-of-the-art large language models, they also produce irrelevant or inaccurate responses to many queries related to niche and specialized domains.

We have developed a conversational AI tool for information synthesis of wireless communication specifications.

Like ChatGPT, the nextgen communications (NGC) copilot offers a question-and-answer interface, but with an enhanced ability to provide more accurate and relevant answers on topics pertaining to wireless communication technical specifications. NGC copilot builds on foundation models, prompt engineering, and retrieval augmented generation approaches; it features a domain-specific database, tailored word embeddings, and a user feedback mechanism. For more accurate responses, it integrates into its database technical specifications and standards that are often overlooked by traditional models due to their niche nature. The system uses a specialized word-embedding model to better understand telecom jargon, improving its query response relevance. Experts can also provide feedback, which helps refine the database and improve answer quality. We have been piloting NGC within our engineering teams and its performance has been excellent.

Proactive management: Network configuration anomaly detection

One of the most common causes of network disruptions today is network configuration errors. Configuration governs the protocols and policies that regulate and control network access, performance, security, billing, and more. Misconfigurations, when they occur, can lead to a frustrating user experience with slow performance, lack of connectivity, or even sweeping service outages. Operators who experience such outages often suffer from loss of reputation and revenue.

Despite the importance of correct network configuration, configuration management today remains a challenge for operators. Manual peer review of configuration changes can have limited effectiveness. Device configurations are often low-level, complex, and long—making them notoriously challenging to audit manually and at scale. On the other hand, automation is also not a panacea; it’s prone to errors, bugs, and mistakes.

The configuration anomaly detection analysis pipeline.

Many configuration errors are obvious in hindsight and could be detected by sufficiently intelligent learning models. For this reason, we have invested in developing AI-driven anomaly-detection tools that can proactively identify and block erroneous configuration changes before they are applied to the network—before they can impact real users. Machine learning is adept at identifying common configuration usage patterns and anti-patterns. It can effectively sift through changes to ignore those that are intentional and alert operators about those that are likely unintentional or erroneous.

Given a collection of similar configuration files (such as JSON, XML, or YAML), our system synthesizes a common template that captures the similarities between these configurations, leaving placeholders for differing values. Using the synthesized template, our system employs a state-of-the-art, unsupervised anomaly-detection technique, known as the isolation forest, to pinpoint likely errors in configurations. These potential anomalies are reported with an anomaly-likelihood score for review. In this way, we aim to help operators with safe and reliable management of their 5G networks by leveraging automated validation of configurations. For real-world scenarios and additional technical details, please read our recent paper.2

Microsoft responsible AI

empowering responsible ai practices

Learn more

We realize that AI and machine learning-based solutions may involve ethical concerns regarding the underlying models, their training data, and associated biases. To address these concerns, the office of responsible AI shepherds the AI projects at Microsoft on risk assessment and mitigation. We work hard to understand the aspects that require improvement regarding bias and discrimination, and we strive to receive broad approval on compliance. We pass on all guidelines to the engineers to ensure responsible usage without slowing progress.

Explore the Microsoft portfolio of products

My hope is that these examples show that foundation models significantly enhance the Azure for Operators portfolio of products. There is a lot more to say, and there are many additional examples of systems we have developed, but I will leave that for another time.

1 Microsoft, Adapting Foundation Models for Operator Data Analytics, Manikata Kotaru, HotNets 2023.

2 Microsoft, Diffy: Data-Driven Bug Finding for Configurations, Siva Kesava Reddy Kakarla, Francis Y. Yan, and Ryan Beckett, April 2024.
The post Empowering operators through generative AI technologies with Azure for Operators appeared first on Azure Blog.
Quelle: Azure

Cloud Cultures, Part 6: Accelerating collective growth in Malaysia

Innovate, Connect, Cultivate

The Cloud Cultures series is an exploration of the intersection between cloud innovation and culture across the globe. 

Malaysia accelerates growth through digital transformation

Amidst the swiftly changing digital landscape, Malaysia stands out as a dynamic force capturing global attention. This nation—enriched by its diverse population comprised of Malays, Indians, Chinese, and more—is home to people and companies that have adeptly embraced innovative technologies, ensuring the benefits extend to all, not just the tech-savvy elite.

Malaysia has established a culture of digital acceleration through industries like energy, farming, and education by striking a balance between growth and the needs of their people. During my travels, I learned how they’ve embraced cloud innovation in a way that allows them to navigate the modern world with confidence and ensure that everyone is along for the ride.

Before setting out to meet with local companies, I joined General Manager of Energy and Utilities for Microsoft Malaysia, Shereeta (full name: Datin Sharifah Shereeta Syed Sheh), for a traditional Malaysian breakfast at her favorite restaurant. We sat down to talk about our upcoming interviews over nasi lemak—a delicious combination of fried anchovies, fish, hard-boiled egg, cucumber, and sambal on fragrant coconut rice, alongside pancakes, coconut grits, and colorful baked treats. Delighted by the food and excited for the day, we parted ways after breakfast. Shereeta headed out to a local chicken farm while I ventured further into the city.

PETRONAS is building a more sustainable world

I began my visit in the heart of Kuala Lumpur at the Golden Triangle, a hub for shopping, commerce, and entertainment. Standing 88-stories tall with a 17-acre park at its base, the PETRONAS Twin Towers are a wonder to behold. The skyscrapers are complete with malls, museums, a philharmonic orchestra, and a skybridge with views of the vibrant city. This is where I met Phuah Aik-Chong, CEO of Petronas Digital, to learn how PETRONAS utilizes the cloud to accelerate digital transformation.

PETRONAS is a dynamic global energy group with presence in over 100 countries. They produce and deliver energy and solutions that power society’s progress, enriching lives for a sustainable future. PETRONAS’ commitment to sustainability starts at the core of their operations and extends throughout their value chain. People are their strength and partners for growth, driving innovation to deliver a unique spectrum of solutions. PETRONAS’ commitment to Malaysia’s progress doesn’t stop at providing oil and gas—they make a concerted effort to provide development opportunities to underserved populations. One such initiative is the BeDigital Bootcamp, which involves upskilling students from various universities in Malaysia. Partnering with Microsoft, they have collaborated on multiple initiatives that reflect the mutual goal of empowering Malaysians to benefit in tandem with the rapid pace of innovation and digital advancements.

Chop Cheong Bee uses e-farming to feed Malaysia

While I stayed in the city, Shereeta took a break from the bustling metropolis and turned down a quiet dirt road. There, she learned about a local company that helps independent chicken farmers use cloud technology to turn their operations into smart farms—improving food security across Malaysia with affordable, high-quality chicken.

Founded in 1985, Chop Cheong Bee began as a poultry trading company, supplying chicken to local markets and establishments in Malaysia. After a brief period of time, they had to close due to an overwhelming number of manual tasks. However, in the late 2000s, they reopened focusing on technology and e-farming practices.

Cloud technology enables Chop Cheong Bee to create environments where chickens can thrive, utilizing a closed and climate-controlled farming system. The solution they developed collects data to inform how much feed is being consumed and the meat conversion ratios, all in real time. Today, Chop Cheong Bee is a crucial poultry supplier that facilitates a sizable portion of the chicken supply in Malaysia.

General Manager of Chop Cheong Bee, Datuk Jeffrey Ng Choon Ngee shared how e-farming is the future:

“With our solution, we can improve the broiler production index by 20 to 30 points. That’s easily a 10 percent improvement. If more farms can achieve this, then the cost of production will drop. And then hopefully, more Malaysians can afford quality poultry.”

Chop Cheong Bee built a system that can produce about 280 to 340 million chickens annually and supply 80 to 100 customers daily. This new way of farming not only provides millions of people with affordable and nutritious meat, but has also attracted a younger, more technology-focused generation of farmers to this vital industry.

Bersama Malaysia ensures citizens are part of the country’s digital acceleration

My final stop in Malaysia was a basketball court to shoot hoops with a recent graduate, Vaashini Palaniappan, who took part in the Bersama Malaysia (Together with Malaysia) program. Alongside sponsors like the Ministry of Education and Microsoft, the initiative teaches students digital skilling, inspiring young students, and women to dream outside the norm and build careers in tech.

Vaashini Palaniappan, data scientist and recent graduate, shared her future aspirations:

“There are so many women in this data and AI field that want to invent something, that want a brighter future. Because of this, I’m inspired to do something different. I want to be inventive using AI.”

Growing up in a small town, Vaashini didn’t have a lot of exposure to technology. But by participating in university programs, she was able to study sciences, learn technical skills, and understand the impact of advanced technologies on medicine. After seeing a close friend pass from cancer, Vaashini said she was determined to become a doctor and leverage innovative technology for good—specifically, to use AI to detect early signs of cancer and build a hyper-personalized treatment plan for patients.

Bersama Malaysia, along with Microsoft’s Code with Barriers program, were created to ensure citizens of Malaysia are a part of the digital acceleration of the country. These programs are empowering Malaysia’s inclusive digital economy and advancing the nation’s digital transformation across the private and public sectors. Malaysia has consistently been a trailblazer in fostering opportunities for its citizens. Through initiatives like Bersama Malaysia, the nation ensures that no one is left behind in the dynamic landscape of transformation.

Innovating together makes change happen

Later that evening, Shereeta and I discussed our journey over my first experience with a popular local fruit: the durian. After getting used to the infamous smell, I snacked on the custard-like meat and reflected on Malaysia’s inspiring commitment to extending growth far beyond the gleaming skyscrapers and urban epicenters. This version of cloud culture ensures that as the pace of progress quickens, it doesn’t come at the cost of anyone being sidelined. As is often the case, I saw in Malaysia that the best way to accelerate growth isn’t racing ahead; it’s moving forward together.

In this ever-changing world, there is always more to experience. See you on my next adventure!

Learn more:

Watch more Cloud Cultures episodes

Find the Azure geography that meets your needs

Cloud Cultures

Explore the ways people across the globe are using Azure technology

Learn more

The post Cloud Cultures, Part 6: Accelerating collective growth in Malaysia appeared first on Azure Blog.
Quelle: Azure

Get started with the latest updates for Dockerfile syntax (v1.7.0)

Dockerfiles are fundamental tools for developers working with Docker, serving as a blueprint for creating Docker images. These text documents contain all the commands a user could call on the command line to assemble an image. Understanding and effectively utilizing Dockerfiles can significantly streamline the development process, allowing for the automation of image creation and ensuring consistent environments across different stages of development. Dockerfiles are pivotal in defining project environments, dependencies, and the configuration of applications within Docker containers.

With new versions of the BuildKit builder toolkit, Docker Buildx CLI, and Dockerfile frontend for BuildKit (v1.7.0), developers now have access to enhanced Dockerfile capabilities. This blog post delves into these new Dockerfile capabilities and explains how you can can leverage them in your projects to further optimize your Docker workflows.

Versioning

Before we get started, here’s a quick reminder of how Dockerfile is versioned and what you should do to update it. 

Although most projects use Dockerfiles to build images, BuildKit is not limited only to that format. BuildKit supports multiple different frontends for defining the build steps for BuildKit to process. Anyone can create these frontends, package them as regular container images, and load them from a registry when you invoke the build.

With the new release, we have published two such images to Docker Hub: docker/dockerfile:1.7.0 and docker/dockerfile:1.7.0-labs.

To use these frontends, you need to specify a #syntax directive at the beginning of the file to tell BuildKit which frontend image to use for the build. Here we have set it to use the latest of the 1.x.x major version. For example:

#syntax=docker/dockerfile:1

FROM alpine

This means that BuildKit is decoupled from the Dockerfile frontend syntax. You can start using new Dockerfile features right away without worrying about which BuildKit version you’re using. All the examples described in this article will work with any version of Docker that supports BuildKit (the default builder as of Docker 23), as long as you define the correct #syntax directive on the top of your Dockerfile.

You can learn more about Dockerfile frontend versions in the documentation. 

Variable expansions

When you write Dockerfiles, build steps can contain variables that are defined using the build arguments (ARG) and environment variables (ENV) instructions. The difference between build arguments and environment variables is that environment variables are kept in the resulting image and persist when a container is created from it.

When you use such variables, you most likely use ${NAME} or, more simply, $NAME in COPY, RUN, and other commands.

You might not know that Dockerfile supports two forms of Bash-like variable expansion:

${variable:-word}: Sets a value to word if the variable is unset

${variable:+word}: Sets a value to word if the variable is set

Up to this point, these special forms were not that useful in Dockerfiles because the default value of ARG instructions can be set directly:

FROM alpine
ARG foo="default value"

If you are an expert in various shell applications, you know that Bash and other tools usually have many additional forms of variable expansion to ease the development of your scripts.

In Dockerfile v1.7, we have added:

${variable#pattern} and ${variable##pattern} to remove the shortest or longest prefix from the variable’s value.

${variable%pattern} and ${variable%%pattern} to remove the shortest or longest prefix from the variable’s value.

${variable/pattern/replacement} to first replace occurrence of a pattern

${variable//pattern/replacement} to replace all occurrences of a pattern

How these rules are used might not be completely obvious at first. So, let’s look at a few examples seen in actual Dockerfiles.

For example, projects often can’t agree on whether versions for downloading your dependencies should have a “v” prefix or not. The following allows you to get the format you need:

# example VERSION=v1.2.3
ARG VERSION=${VERSION#v}
# VERSION is now '1.2.3'

In the next example, multiple variants are used by the same project:

ARG VERSION=v1.7.13
ADD https://github.com/containerd/containerd/releases/download/${VERSION}/containerd-${VERSION#v}-linux-amd64.tar.gz /

To configure different command behaviors for multi-platform builds, BuildKit provides useful built-in variables like TARGETOS and TARGETARCH. Unfortunately, not all projects use the same values. For example, in containers and the Go ecosystem, we refer to 64-bit ARM architecture as arm64, but sometimes you need aarch64 instead.

ADD https://github.com/oven-sh/bun/releases/download/bun-v1.0.30/bun-linux-${TARGETARCH/arm64/aarch64}.zip /

In this case, the URL also uses a custom name for AMD64 architecture. To pass a variable through multiple expansions, use another ARG definition with an expansion from the previous value. You could also write all the definitions on a single line, as ARG allows multiple parameters, which may hurt readability.

ARG ARCH=${TARGETARCH/arm64/aarch64}
ARG ARCH=${ARCH/amd64/x64}
ADD https://github.com/oven-sh/bun/releases/download/bun-v1.0.30/bun-linux-${ARCH}.zip /

Note that the example above is written in a way that if a user passes their own –build-arg ARCH=value, then that value is used as-is.

Now, let’s look at how new expansions can be useful in multi-stage builds.

One of the techniques described in “Advanced multi-stage build patterns” shows how build arguments can be used so that different Dockerfile commands run depending on the build-arg value. For example, you can use that pattern if you build a multi-platform image and want to run additional COPY or RUN commands only for specific platforms. If this method is new to you, you can learn more about it from that post.

In summarized form, the idea is to define a global build argument and then define build stages that use the build argument value in the stage name while pointing to the base of your target stage via the build-arg name.

Old example:

ARG BUILD_VERSION=1

FROM alpine AS base
RUN …

FROM base AS branch-version-1
RUN touch version1

FROM base AS branch-version-2
RUN touch version2

FROM branch-version-${BUILD_VERSION} AS after-condition

FROM after-condition
RUN …

When using this pattern for multi-platform builds, one of the limitations is that all the possible values for the build-arg need to be defined by your Dockerfile. This is problematic as we want Dockerfile to be built in a way that it can build on any platform and not limit it to a specific set. 

You can see other examples here and here of Dockerfiles where dummy stage aliases must be defined for all architectures, and no other architecture can be built. Instead, the pattern we would like to use is that there is one architecture that has a special behavior, and everything else shares another common behavior.

With new expansions, we can write this to demonstrate running special commands only on RISC-V, which is still somewhat new and may need custom behavior:

#syntax=docker/dockerfile:1.7

ARG ARCH=${TARGETARCH#riscv64}
ARG ARCH=${ARCH:+"common"}
ARG ARCH=${ARCH:-$TARGETARCH}

FROM –platform=$BUILDPLATFORM alpine AS base-common
ARG TARGETARCH
RUN echo "Common build, I am $TARGETARCH" > /out

FROM –platform=$BUILDPLATFORM alpine AS base-riscv64
ARG TARGETARCH
RUN echo "Riscv only special build, I am $TARGETARCH" > /out

FROM base-${ARCH} AS base

Let’s look at these ARCH definitions more closely.

The first sets ARCH to TARGETARCH but removes riscv64 from the value.

Next, as we described previously, we don’t actually want the other architectures to use their own values but instead want them all to share a common value. So, we set ARCH to common except if it was cleared from the previous riscv64 rule. 

Now, if we still have an empty value, we default it back to $TARGETARCH.

The last definition is optional, as we would already have a unique value for both cases, but it makes the final stage name base-riscv64 nicer to read.

Additional examples of including multiple conditions with shared conditions, or conditions based on architecture variants can be found in this GitHub Gist page.

Comparing this example to the initial example of conditions between stages, the new pattern isn’t limited to just controlling the platform differences of your builds but can be used with any build-arg. If you have used this pattern before, then you can effectively now define an “else” clause, whereas previously, you were limited to only “if” clauses.

Copy with keeping parent directories

The following feature has been released in the “labs” channel. Define the following at the top of your Dockerfile to use this feature.

#syntax=docker/dockerfile:1.7-labs

When you are copying files in your Dockerfile, for example, do this:

COPY app/file /to/dest/dir/

This example means the source file is copied directly to the destination directory. If your source path was a directory, all the files inside that directory would be copied directly to the destination path.

What if you have a file structure like the following:

.
├── app1
│ ├── docs
│ │ └── manual.md
│ └── src
│ └── server.go
└── app2
└── src
└── client.go

You want to copy only files in app1/src, but so that the final files at the destination would be /to/dest/dir/app1/src/server.go and not just /to/dest/dir/server.go.

With the new COPY –parents flag, you can write:

COPY –parents /app1/src/ /to/dest/dir/

This will copy the files inside the src directory and recreate the app1/src directory structure for these files.

Things get more powerful when you start to use wildcard paths. To copy the src directories for both apps into their respective locations, you can write:

COPY –parents */src/ /to/dest/dir/

This will create both /to/dest/dir/app1 and /to/dest/dir/app2, but it will not copy the docs directory. Previously, this kind of copy was not possible with a single command. You would have needed multiple copies for individual files (as shown in this example) or used some workaround with the RUN –mount instruction instead.

You can also use double-star wildcard (**) to match files under any directory structure. For example, to copy only the Go source code files anywhere in your build context, you can write:

COPY –parents **/*.go /to/dest/dir/

If you are thinking about why you would need to copy specific files instead of just using COPY ./ to copy all files, remember that your build cache gets invalidated when you include new files in your build. If you copy all files, the cache gets invalidated when any file is added or changed, whereas if you copy only Go files, only changes in these files influence the cache.

The new –parents flag is not only for COPY instructions from your build context, but obviously, you can also use them in multi-stage builds when copying files between stages using COPY –from. 

Note that with COPY –from syntax, all source paths are expected to be absolute, meaning that if the –parents flag is used with such paths, they will be fully replicated as they were in the source stage. That may not always be desirable, and instead, you may want to keep some parents but discard and replace others. In that case, you can use a special /./ relative pivot point in your source path to mark which parents you wish to copy and which should be ignored. This special path component resembles how rsync works with the –relative flag.

#syntax=docker/dockerfile:1.7-labs
FROM … AS base
RUN ./generate-lot-of-files -o /out/
# /out/usr/bin/foo
# /out/usr/lib/bar.so
# /out/usr/local/bin/baz

FROM scratch
COPY –from=base –parents /out/./**/bin/ /
# /usr/bin/foo
# /usr/local/bin/baz

This example above shows how only bin directories are copied from the collection of files that the intermediate stage generated, but all the directories will keep their paths relative to the out directory. 

Exclusion filters

The following feature has been released in the “labs” channel. Define the following at the top of your Dockerfile to use this feature:

#syntax=docker/dockerfile:1.7-labs

Another related case when moving files in your Dockerfile with COPY and ADD instructions is when you want to move a group of files but exclude a specific subset. Previously, your only options were to use RUN –mount or try to define your excluded files inside a .dockerignore file. 

.dockerignore files, however, are not a good solution for this problem, because they only list the files excluded from the client-side build context and not from builds from remote Git/HTTP URLs and are limited to one per Dockerfile. You should use them similarly to .gitignore to mark files that are never part of your project but not as a way to define your application-specific build logic.

With the new –exclude=[pattern] flag, you can now define such exclusion filters for your COPY and ADD commands directly in the Dockerfile. The pattern uses the same format as .dockerignore.

The following example copies all the files in a directory except Markdown files:

COPY –exclude=*.md app /dest/

You can use the flag multiple times to add multiple filters. The next example excludes Markdown files and also a file called README:

COPY –exclude=*.md –exclude=README app /dest/

Double-star wildcards exclude not only Markdown files in the copied directory but also in any subdirectory:

COPY –exclude=**/*.md app /dest/

As in .dockerignore files, you can also define exceptions to the exclusions with ! prefix. The following example excludes all Markdown files in any copied directory, except if the file is called important.md — in that case, it is still copied.

COPY –exclude=**/*.md –exclude=!**/important.md app /dest/

This double negative may be confusing initially, but note that this is a reversal of the previous exclude rule, and “include patterns” are defined by the source parameter of the COPY instruction.

When using –exclude together with previously described –parents copy mode, note that the exclude patterns are relative to the copied parent directories or to the pivot point /./ if one is defined. See the following directory structure for example:

assets
├── app1
│ ├── icons32x32
│ ├── icons64x64
│ ├── notes
│ └── backup
├── app2
│ └── icons32x32
└── testapp
└── icons32x32

COPY –parents –exclude=testapp assets/./**/icons* /dest/

This command would create the directory structure below. Note that only directories with the icons prefix were copied, the root parent directory assets was skipped as it was before the relative pivot point, and additionally, testapp was not copied as it was defined with an exclusion filter.

dest
├── app1
│ ├── icons32x32
│ └── icons64x64
└── app2
└── icons32x32

Conclusion

We hope this post gave you ideas for improving your Dockerfiles and that the patterns shown here will help you describe your build more efficiently. Remember that your Dockerfile can start using all these features today by defining the #syntax line on top, even if you haven’t updated to the latest Docker yet.

For a full list of other features in the new BuildKit, Buildx, and Dockerfile releases, check out the changelogs:

BuildKit v0.13.0

Buildx v0.13.0

Dockerfile v1.7.0 v1.7.0-labs

Thanks to community members @tstenner, @DYefimov, and @leandrosansilva for helping to implement these features!

If you have issues or suggestions you want to share, let us know in the issue tracker.

Learn more

Subscribe to the Docker Newsletter.

Get the latest release of Docker Desktop.

Vote on what’s next! Check out our public roadmap.

Have questions? The Docker community is here to help.

New to Docker? Get started.

Quelle: https://blog.docker.com/feed/

In den Wissensdatenbanken für Amazon Bedrock können Sie jetzt Prompts und die Anzahl der Abrufergebnisse anpassen

Wir freuen uns, Ihnen mitteilen zu können, dass Sie in den Wissensdatenbanken für Amazon Bedrock jetzt benutzerdefinierte Prompts erstellen können, um die vom Basismodell (FM) generierten Antworten besser kontrollieren zu können. Darüber hinaus können Sie die Anzahl der abgerufenen Passagen konfigurieren, was die Genauigkeit verbessert, indem dem FM zusätzlicher Kontext zur Verfügung gestellt wird.
Quelle: aws.amazon.com

Prognose, Kapazitäts- und Zeitplanung in Amazon Connect ist jetzt allgemein in vier weiteren AWS-Regionen verfügbar

Prognose, Kapazitäts- und Zeitplanung in Amazon Connect ist jetzt allgemein in folgenden AWS-Regionen verfügbar: Europa (Frankfurt), Asien-Pazifik (Singapur), Asien-Pazifik (Tokio) und Asien-Pazifik (Seoul). Mit diesen Funktionen können Sie prognostizieren, zuweisen und überprüfen, ob die richtige Anzahl von Kundendienstmitarbeitern zur richtigen Zeit eingeplant ist, um Ihre betrieblichen Ziele zu erreichen. Mithilfe von Funktionen für Machine Learning (ML) können Sie das Kontaktvolumen und die Ankunftsraten vorhersagen, diese Prognosen in den voraussichtlichen Personalbedarf umwandeln und Schichten für Kundendienstmitarbeiter erstellen. Mit Prognosen, Kapazitäts- und Zeitplanung können Sie, Abläufe im Kontakt-Center optimieren, Serviceziele erreichen und die Zufriedenheit von KUndendienstmitarbeitern und Kunden verbessern.
Quelle: aws.amazon.com

Amazon SageMaker Canvas kündigt ein neue Preissystem für das Training tabellarischer Modelle an

Wir sind erfreut Ihnen das neue Preissystem für das Training von benutzerdefinierten tabellarischen Modellen in Amazon SageMaker Canvas bekannt geben zu dürfen, einem No-Code-Tool, mit dem Kunden hochpräzise ML-Modelle erstellen können, ohne eine Zeile Code zu schreiben. SageMaker Canvas unterstützt numerische Vorhersagen (Regression), Vorhersagen mit 2 Kategorien (binäre Klassifikation), Vorhersagen mit 3 oder mehr Kategorien (Mehrklassen-Klassifikation) und Zeitreihenprognosen für tabellarische Modelle. Bisher basierten die Gebühren für das Training eines Modells auf der Anzahl an Zellen in einem Datensatz, der zum Trainieren des Modells verwendet wurde. Jetzt basieren die Gebühren auf den Trainings- und Verarbeitungszeiten, die zum Training des Modells verwendet werden. 
Quelle: aws.amazon.com

Wissensdatenbanken für Amazon Bedrock unterstützen jetzt private Netzwerkrichtlinien für OpenSearch Serverless

Wissensdatenbanken für Amazon Bedrock sind eine vollständig verwaltete Retrieval-Augmented Generation (RAG)-Funktion, die es Ihnen ermöglicht, Basismodelle (FMs) mit internen Unternehmensdatenquellen zu verbinden, um relevantere, kontextspezifische und genauere Antworten zu erhalten. Wir freuen uns, Ihnen mitteilen zu können, dass Wissensdatenbanken jetzt private Netzwerkrichtlinien für Amazon OpenSearch Serverless (OSS) unterstützen.
Quelle: aws.amazon.com