Graphcore Poplar SDK Container Images Now Available on Docker Hub

Graphcore’s Poplar® SDK is available for developers to access through Docker Hub, with Graphcore joining Docker’s Verified Publisher Program. Together with Docker, we’re distributing our software stack as container images, enabling developers to easily build, manage and deploy ML applications on Graphcore IPU systems.

We continue to enhance the developer experience to make our hardware and software even easier to use. Just over a year ago we introduced a selection of pre-built Docker containers for users. Now, we are making our Poplar SDK, PyTorch for IPU, TensorFlow for IPU and Tools fully accessible to everyone in the Docker Hub community as part of our mission to drive innovation.

Here’s more information on what’s in it for developers and how to get started.

Why Docker is so important to our community

Docker has become the primary source for pulling container images – according to the latest Index Report, there’s been a total of 396 billion all-time pulls on Docker Hub. Furthermore, Docker Hub remains one of the “most wanted, loved and used” developer tools based on the 2021 Stack Overflow Survey answered by 80,000 developers.

For IPU developers, our Docker container images simplify and accelerate application development workflows being deployed in production on IPU systems by supplying pre-packaged runtime environments for applications built using PyTorch, TensorFlow or directly with Graphcore’s Poplar SDK. Containerised applications provide increased portability of applications with consistent, repeatable execution and are an important enabler for many MLOps frameworks.

What’s available for developers?

As of today, developers can freely install our Poplar Software stack, co-designed with the IPU (Intelligence Processing Unit), specifically for machine intelligence applications. Poplar is Graphcore’s graph toolchain which sits at the core of our easy-to-use and flexible software development environment fully integrated with standard machine learning frameworks so developers can easily port existing models. For developers who want full control to exploit maximum performance from the IPU, Poplar enables direct IPU programming in Python and C++ through PopART (Poplar Advanced Runtime).

Our Poplar SDK images can be pulled via the following repositories:

Poplar SDK – contains Poplar, PopART and tools to interact with IPU devices PyTorch for IPU – contains everything in the Poplar SDK repo with PyTorch pre-installedTensorFlow for IPU – contains everything in the Poplar SDK repo with TensorFlow 1 or 2 pre-installedTools – contains management and diagnostic tools for IPU devices

And as part of the Docker Verified Publisher Program, Graphcore container images are exempt from rate limiting — meaning that developers have unlimited container image requests for Poplar, regardless of their Docker Hub subscription.

Getting Started with Poplar on Docker

The Poplar Docker containers encapsulate everything needed to run models in IPU in a complete filesystem (i.e. Graphcore’s Poplar® SDK, runtime environment, system tools, configs, and libraries). In order to use these images and run IPU code, you will need to complete the following steps:

1. Install Docker on the host machine2. Pull Graphcore’s Poplar SDK container images from Docker Hub3. Prepare Access to IPUs4. Verify IPU accessibility with Docker container5. Sample App Code on IPUs

Install Docker on the host machine

Docker installation varies based on operating system, version, and processor. 

You can follow Docker’s getting started guide.

Pull Graphcore’s Poplar SDK container images from Docker Hub

Once Docker is installed, you can run commands to download our hosted images from Docker Hub and run them in the host machine. The Poplar SDK container images can be pulled from the Graphcore Poplar repository on Docker Hub.

There are four repositories and these repositories may contain multiple images based on the SDK version, OS, and architecture.

graphcore/pytorchgraphcore/tensorflowgraphcore/poplargraphcore/tools

Pulling from the framework repo downloads the latest version of the SDK compiled for AMD host processor by default.

To pull the latest TensorFlow image use:

$ docker pull graphcore/tensorflow

If you want to select a specific build for a specific SDK version and processor, you can configure the tags based on Docker Image Tags.

Prepare Access to IPUs

To talk to the IPUs in PODs, we must configure the connection between the host machines and the IPUs – the IPU over Fabric (IPUoF). The information that Poplar needs to access devices can be passed via an IPUoF configuration file which is, by default, written to a directory in your home directory (~/.ipuof.conf.d). The configuration files are useful when the Poplar hosts do not have direct network access to the V-IPU controller (for security reasons, for example). 

If you are using Graphcloud, the IPUoF default config file is generated every time a new user is created and added to the POD. Check if there are .conf files inside that folder (e.g. ~/.ipuof.conf.d/lr21-3-16ipu.conf). If you have this setup, you can proceed to the next step.

If not available, you will need to configure Poplar to connect to the V-IPU server by following the V-IPU Guide: Getting Started. Take note to save your IPUoF config file in the folder ~/.ipuof.conf.d to run the scripts in the next section.

Verify IPU accessibility with Docker container

Now that you have the container ready, you can check if the IPU is accessible from inside the container.

List the IPU devices within the context of the container by running the following:

$ docker run –rm –ulimit memlock=-1:-1 –net=host –cap-add=IPC_LOCK –device=/dev/infiniband –ipc=host -v ~/.ipuof.conf.d/:/etc/ipuof.conf.d -it graphcore/tools gc-info -l

Running a sample TensorFlow app

First, get the code from the Graphcore tutorials repository in GitHub.

$ git clone https://github.com/graphcore/tutorials.git

$ cd tutorials

The Docker container is an isolated environment. It will come empty and not have access to the host machine’s file system. In order to use data from your host machine, the data needs to be accessible within the Docker container. 

You can make the data accessible by mounting directories as volumes to share data between the host machine and the Docker container environment. 

A common pattern when working with a Docker-based development environment is to mount the current directory into the container (as described in Section 2.2, Mounting directories from the host), then set the working directory inside the container with -w <dir name>. For example, -v “$(pwd):/app” -w /app.

To run the mnist example in the TensorFlow container, you can use the following command which mounts the tutorials repo into the docker container and runs it.

$ docker run –rm –ulimit memlock=-1:-1 –net=host –cap-add=IPC_LOCK –device=/dev/infiniband –ipc=host -v ~/.ipuof.conf.d/:/etc/ipuof.conf.d -it -v “$(pwd):/app” -w /app graphcore/tensorflow:2 python3 simple_applications/tensorflow2/mnist/mnist.py

This guest blog post originally appeared here.
The post Graphcore Poplar SDK Container Images Now Available on Docker Hub appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

How spam detection taught us better tech support

Information Technology teams, especially in help desk and support, need a way to track what problems people are having. Ideally they also can know how those problems change over time, especially when technology or policy shifts.Imagine you are in charge of sending a newspaper delivery team to different neighborhoods. Each person has a bicycle, so you give them a route, and they leave the papers at the right doors. But the roads change. Every day they change. It’s chaos.What do you do when routes are changing constantly?  How do you provide the information needed when the context is shifting all the time?In an IT context we run into similar challenges with traditional problem management frameworks such as ITIL 4, which tend to always assume a fixed, well-defined catalog of services. That way every issue that the IT folks solve is tracked and accounted for. That connection back to the catalog allows insight into what’s causing issues, or where outages or incidents may be impacting a large group of employees. At Google we don’t have that. In part because we focus on putting the user first, and so we focus on getting people back to a productive state as job #1. Also because products, services and issues are always shifting–just like the roads, the route is never the same, even if the goal remains consistent. That means users come into our IT service desk with new problem types everyday.Our tech support team, called Techstop, acts as the one-stop shop for all IT issues, and supports people across chat, email and video channels. They need to remain adaptable to new problems Googlers experience and new products they use. In order to track what problems might be on the rise, the Techstop team needs a way to catalog what tools, applications and services are in use at Google. Thinking back to the newspaper delivery routes, we used a rough approximate map, rather than a very detailed one, giving us a taxonomy of services that was “good enough” for most of our use cases. We got some useful data out of it, but it didn’t give us very granular insight.Need for innovationCovid-19 put a new focus on scalable problem understanding, specifically for everyday employee IT issues. With so much of the workforce moved to a work-from-home model, we really needed to know where employees were experiencing technology pain. It’s as if whole new neighborhoods popped into existence overnight, but our newspaper delivery crew was the same. More ground to cover, with totally novel street maps.Furthermore, products used everyday for productivity, such as Google Meet, began to see exponential growth in usage, causing scaling issues and outages. These product teams looked to the Techstop organization to help them prioritize the ever increasing list of feature requests and bugs being filled every day.Ultimately the “good enough” problem taxonomy failed to produce truly helpful insights. We could find out which products were being affected the most, but not what issues people were having with those products. Even worse, new issues that were unique to the work-from-home model were being hidden by the fact that the catalog could not update in time to catch the rapidly changing problem space underneath it.Borrowing spam techTaking a look around other efforts at Google, the Techstop team found examples of solving a similar problem: detecting new patterns quickly in rapidly changing data.Gmail handles spam filtering for over a billion people. Those engineers had thought through “how do we detect a new spam campaign quickly?”  Spammers rapidly send bulk messages with slight variations in content (noise, misspellings, etc.) Most classification attempts would become a game of cat and mouse since it takes classifiers some time to learn about new patterns.Invoking a trend identification engine using unsupervised density clustering on unstructured text unlocked the ability for Gmail to detect ephemeral spam campaigns more quickly.The Techstop problem had a similar shape to it. Issues caused by rapidly changing products caused highly dynamic user journeys for both employees and the IT professionals troubleshooting these issues. The tickets filed — like the spam emails — were similar, with slight differences in spelling and word choice.Density clusteringIn contrast to more rigid approaches, such as centroid-based algorithms like k-means, density-based clustering is better suited to large and highly heterogeneous data sets, which may contain clusters of drastically variant size. This flexibility helps us tackle the task of problem identification across the entire scope of the company, which requires the ability to detect and distinguish small-but-significant perturbations in the presence of large-but-stable patterns.Our implementation uses ClustOn, an in-house technology with a hybrid approach that incorporates density-based clustering. But a more time-tested algorithm such as DBSCAN — an open-source implementation of which is available via scikit-learn’s clustering module — could be leveraged to similar effect.Middle of the road solution using MLPiggy-backing off of what Gmail was able to do using density clustering techniques, the Techstop team built a robust solution to tracking problems in a way that solved the rigid taxonomy problem. With density clustering, the taxonomy buckets are redefined as trending clusters and provide an index of issues happening in real-time within the company. Importantly, these buckets emerge naturally, rather than being defined ahead of time by the Engineering or Tech Support teams.By using the technology built for billions of email accounts, we knew we could handle the scale of Google’s support requests. And the solutions would be more flexible than a tightly defined taxonomy, without compromising on relevance or granularity.  The team took it one step further by modeling cluster behavior using Poisson regression and implemented anomaly detection measures to alert operations teams in real time about ongoing outages, or poorly executed changes. With a lightweight operations team and this new technology, Techstop was able to find granular insights that would have taken an entire dedicated team to manually comb through and aggregate each incident.The combination of ML and Operations transformed Techstop data into a valuable reference for product managers and engineering teams looking to understand the issues users face with their products in an enterprise environment. How it worksTo bring it all together, we built a ML pipeline that we call Support Insights, so we could automatically distill summary data from the many interactions and tickets we received. The Support Insights Pipeline combines machine learning, human validation and probabilistic analysis  together in a single systems dynamics approach. As data moves through this pipeline, they are:Extracted – Uses the BigQuery API to store and extract, train and load support data. To ingest the 1M+ amount of IT related support data.Processed Part-of-speech tagging, PII Redaction and TF-IDF transformations to model support data for our clustering algorithmsClustered Centroid-based clustering runs in timed batches with persistent snaphotting of previous run states to maintain cluster ids and track behavior of clusters over time.Scored Uses Poisson Regression to model both long-term and short-term behavior of cluster trends and calculates the difference between the two to measure deviation. This deviation score is used to detect anomalous behavior within a trend.Operationalized Trends with an anomalous score over a certain threshold trigger an IssueTracker API bug. This bug is then picked up by operations teams for relevant deep dive and incident tracking.Resampled – Uses statistical methods to estimate proportions of customer user journeys (CUJs) within trendsCategorized/mapped – We work with the Operations teams to map trend proportions to User Journey SegmentsIn our next post we’ll detail what technologies and methods we used for these seven steps, and walk through how you could use a similar pipeline yourself. To get started start by loading your data into BigQuery and use BigQuery ML to cluster your support data.Related ArticleHow to provide better search results with AI rankingAutomatic scoring and natural language models can make internal search results much more relevant and timely, especially when new trends …Read Article
Quelle: Google Cloud Platform

Amazon ECS fügt jetzt Informationen zum Zustand von Container-Instances hinzu

Amazon Elastic Container Service (Amazon ECS) bietet Kunden jetzt einen besseren Einblick in den Zustand ihrer Computing-Infrastruktur. Kunden, die containerisierte Workloads mit Amazon ECS auf der Amazon Elastic Compute Cloud (Amazon EC2) oder vor Ort mit Amazon ECS Anywhere ausführen, können jetzt den Zustandsstatus der Container-Laufzeit (z. B. Docker) für ihre Container-Instances direkt über die Amazon-ECS-API abfragen. Dies hilft den Kunden, die Ausfallsicherheit ihrer Anwendungen zu verbessern.
Quelle: aws.amazon.com

Zentrale Verwaltung des Zugriffs für JumpCloud-Benutzer mit AWS Single Sign-On

Kunden können nun ihre JumpCloud-Verzeichnis-Plattform (JumpCloud) einmal mit Single Sign-On (SSO) von Amazon Web Services verbinden, den Zugriff auf AWS zentral in AWS SSO verwalten und Endbenutzern ermöglichen, sich mit JumpCloud anzumelden, um auf alle ihre zugewiesenen AWS-Konten zuzugreifen. Die Integration hilft Kunden, die AWS-Zugriffsverwaltung über mehrere Konten hinweg zu vereinfachen und gleichzeitig das vertraute JumpCloud-Erlebnis für Administratoren, die Identitäten verwalten, und für Endbenutzer bei der Anmeldung beizubehalten. AWS SSO und JumpCloud nutzen standardbasierte Automatisierung zur Bereitstellung von Benutzern und Gruppen in AWS SSO, wodurch Kunden Verwaltungszeit sparen und die Sicherheit erhöhen können.
Quelle: aws.amazon.com