GCP export BUCKET YOURBUCKET Before launching training job please copy the raw data and define the environmental variables the bucket for staging and the bucket where you are going to store data as well as training job s outputs TensorFlow Profiling Examples gsutil m cp gs cloud training demos babyweight preproc gs BUCKET babyweight preproc Profiler hooks You also need to have installed export BUCKETSTAGING YOURSTAGINGBUCKET The code below is based on this you can find more

Answer:
# TensorFlow Profiling Examples

Before launching training job, please copy the raw data and define the environmental variables (the bucket for staging and the bucket where you are going to store data as well as training job's outputs)
`export BUCKET=YOUR_BUCKET
gsutil -m cp gs://cloud-training-demos/babyweight/preproc/* gs://$BUCKET/babyweight/preproc/
export BUCKET_STAGING=YOUR_STAGING_BUCKET`
You also need to have [bazel](https://docs.bazel.build/versions/master/install.html) installed.
The code below is based on this [codelab](https://codelabs.developers.google.com/codelabs/scd-babyweight2/index.html?index=..%2F..%2Fcloud-quest-scientific-data#0) (you can find more [here](https://github.com/GoogleCloudPlatform/training-data-analyst/tree/master/blogs/babyweight)).

## Profiler hooks
You can dump profiles for a every *n*-th step. We are going to demonstrate how to collect dumps both in distributed mode as well as when training is don on a single machine (including training with a GPU accelerator).
After you've trained a model (see examples below), you need to copy the dumps localy in order to inspect them. You can do it as follows:
```shell
rm -rf /tmp/profiler
mkdir -p /tmp/profiler
gsutil -m cp -r $OUTDIR/timeline*.json /tmp/profiler
```
And now you can launch a trace event profiling tool in your Chrome browser (chrome://tracing), load a specific timeline and visually inspect it.

### Training on a single CPU machine: BASIC CMLE tier
You can launch the job as following:
```shell
OUTDIR=gs://$BUCKET/babyweight/hooks_basic
JOBNAME=babyweight_$(date -u +%y%m%d_%H%M%S)
gsutil -m rm -rf $OUTDIR
gcloud ml-engine jobs submit training $JOBNAME \
  --region=us-west1 \
  --module-name=trainer-hooks.task \
  --package-path=trainer-hooks \
  --job-dir=$OUTDIR \
  --staging-bucket=gs://$BUCKET_STAGING \
  --scale-tier=BASIC \
  --runtime-version="1.10" \
  -- \
  --bucket=$BUCKET/babyweight \
  --output_dir=${OUTDIR} \
  --eval_int=1200 \
  --train_steps=50000
```

### Distributed training on CPUs: STANDARD tier
You can launch the job as following:
```shell
OUTDIR=gs://$BUCKET/babyweight/hooks_standard
JOBNAME=babyweight_$(date -u +%y%m%d_%H%M%S)
gsutil -m rm -rf $OUTDIR
gcloud ml-engine jobs submit training $JOBNAME \
  --region=us-west1 \
  --module-name=trainer-hooks.task \
  --package-path=trainer-hooks \
  --job-dir=$OUTDIR \
  --staging-bucket=gs://$BUCKET_STAGING \
  --scale-tier=STANDARD_1 \
  --runtime-version="1.10" \
  -- \
  --bucket=$BUCKET/babyweight \
  --output_dir=${OUTDIR} \
  --train_steps=50000
```

### Training on GPU:
```shell
OUTDIR=gs://$BUCKET/babyweight/hooks_gpu
JOBNAME=babyweight_$(date -u +%y%m%d_%H%M%S)
gsutil -m rm -rf $OUTDIR
gcloud ml-engine jobs submit training $JOBNAME \
  --region=us-west1 \
  --module-name=trainer-hooks.task \
  --package-path=trainer-hooks \
  --job-dir=$OUTDIR \
  --staging-bucket=gs://$BUCKET_STAGING \
  --scale-tier=BASIC_GPU \
  --runtime-version="1.10" \
  -- \
  --bucket=$BUCKET/babyweight \
  --output_dir=${OUTDIR} \
  --batch_size=8192 \
  --train_steps=21000
```

### Defining you own schedule
```shell
OUTDIR=gs://$BUCKET/babyweight/hooks_basic-ext
JOBNAME=babyweight_$(date -u +%y%m%d_%H%M%S)
gsutil -m rm -rf $OUTDIR
gcloud ml-engine jobs submit training $JOBNAME \
  --region=us-west1 \
  --module-name=trainer-hooks-ext.task \
  --package-path=trainer-hooks-ext \
  --job-dir=$OUTDIR \
  --staging-bucket=gs://$BUCKET_STAGING \
  --scale-tier=BASIC \
  --runtime-version="1.10" \
  -- \
  --bucket=$BUCKET/babyweight \
  --output_dir=${OUTDIR} \
  --eval_int=1200 \
  --train_steps=15000
```

## Deep profiling
We can collect a deep profiling dump that can be later analyzed with a profiling CLI tool or with a profiler-ui as described in a post (ADD LINK HERE).
Launch the training job as following:
```shell
OUTDIR=gs://$BUCKET/babyweight/profiler_standard
JOBNAME=babyweight_$(date -u +%y%m%d_%H%M%S)
gsutil -m rm -rf $OUTDIR
gcloud ml-engine jobs submit training $JOBNAME \
  --region=us-west1 \
  --module-name=trainer-deep-profiling.task \
  --package-path=trainer-deep-profiling \
  --job-dir=$OUTDIR \
  --staging-bucket=gs://$BUCKET_STAGING \
  --scale-tier=STANDARD_1 \
  --runtime-version="1.10" \
  -- \
  --bucket=$BUCKET/babyweight \
  --output_dir=${OUTDIR} \
  --train_steps=100000
```

### Profiler CLI
1. In order to use [profiler CLI](https://github.com/tensorflow/tensorflow/blob/9590c4c32dd4346ea5c35673336f5912c6072bf2/tensorflow/core/profiler/README.md), you need to build the profiler first:
`git clone https://github.com/tensorflow/tensorflow.git
cd tensorflow
bazel build -c opt tensorflow/core/profiler:profiler`
2. Copy dumps locally:
`rm -rf /tmp/profiler
mkdir -p /tmp/profiler
gsutil -m cp -r $OUTDIR/profiler /tmp`
3. Launch the profiler with `bazel-bin/tensorflow/core/profiler/profiler --profile_path=/tmp/profiler/$(ls /tmp/profiler/ | head -1)`

### Profiler UI
You can also use a [profiler-ui](https://github.com/tensorflow/profiler-ui), i.e. a web interface for a tensorflow profiler.
1. If you'd like to install [pprof](https://github.com/google/pprof), please follow the [installation instructions](https://github.com/google/pprof#building-pprof).
2. Clone the repository:
`git clone https://github.com/tensorflow/profiler-ui.git
cd profiler-ui`
3. Copy dumps locally:
`rm -rf /tmp/profiler
mkdir -p /tmp/profiler
gsutil -m cp -r $OUTDIR/$MODEL/profiler /tmp`
4. Launch the profiler with `python ui.py --profile_context_path=/tmp/profiler/$(ls /tmp/profiler/ | head -1)`

TensorFlow Profiling Examples  Before launching training job  please copy the raw data and define the environmental variables  the bucket for staging and the bucket where you are going to store data as well as training job s outputs   export BUCKET YOUR BUCKET gsutil  m cp gs   cloud training demos babyweight preproc   gs    BUCKET babyweight preproc  export BUCKET STAGING YOUR STAGING BUCKET  You also need to have  bazel  https   docs bazel build versions master install html  installed  The code below is based on this  codelab  https   codelabs developers google com codelabs scd babyweight2 index html index    2F   2Fcloud quest scientific data 0   you can find more  here  https   github com GoogleCloudPlatform training data analyst tree master blogs babyweight        Profiler hooks You can dump profiles for a every  n  th step  We are going to demonstrate how to collect dumps both in distributed mode as well as when training is don on a single machine  including training with a GPU accelerator   After you ve trained a model  see examples below   you need to copy the dumps localy in order to inspect them  You can do it as follows     shell rm  rf  tmp profiler mkdir  p  tmp profiler gsutil  m cp  r  OUTDIR timeline  json  tmp profiler     And now you can launch a trace event profiling tool in your Chrome browser  chrome   tracing   load a specific timeline and visually inspect it       Training on a single CPU machine  BASIC CMLE tier You can launch the job as following     shell OUTDIR gs    BUCKET babyweight hooks basic JOBNAME babyweight   date  u   y m d  H M S  gsutil  m rm  rf  OUTDIR gcloud ml engine jobs submit training  JOBNAME       region us west1       module name trainer hooks task       package path trainer hooks       job dir  OUTDIR       staging bucket gs    BUCKET STAGING       scale tier BASIC       runtime version  1 10               bucket  BUCKET babyweight       output dir   OUTDIR        eval int 1200       train steps 50000          Distributed training on CPUs  STANDARD tier You can launch the job as following     shell OUTDIR gs    BUCKET babyweight hooks standard JOBNAME babyweight   date  u   y m d  H M S  gsutil  m rm  rf  OUTDIR gcloud ml engine jobs submit training  JOBNAME       region us west1       module name trainer hooks task       package path trainer hooks       job dir  OUTDIR       staging bucket gs    BUCKET STAGING       scale tier STANDARD 1       runtime version  1 10               bucket  BUCKET babyweight       output dir   OUTDIR        train steps 50000          Training on GPU     shell OUTDIR gs    BUCKET babyweight hooks gpu JOBNAME babyweight   date  u   y m d  H M S  gsutil  m rm  rf  OUTDIR gcloud ml engine jobs submit training  JOBNAME       region us west1       module name trainer hooks task       package path trainer hooks       job dir  OUTDIR       staging bucket gs    BUCKET STAGING       scale tier BASIC GPU       runtime version  1 10               bucket  BUCKET babyweight       output dir   OUTDIR        batch size 8192       train steps 21000          Defining you own schedule    shell OUTDIR gs    BUCKET babyweight hooks basic ext JOBNAME babyweight   date  u   y m d  H M S  gsutil  m rm  rf  OUTDIR gcloud ml engine jobs submit training  JOBNAME       region us west1       module name trainer hooks ext task       package path trainer hooks ext       job dir  OUTDIR       staging bucket gs    BUCKET STAGING       scale tier BASIC       runtime version  1 10               bucket  BUCKET babyweight       output dir   OUTDIR        eval int 1200       train steps 15000         Deep profiling We can collect a deep profiling dump that can be later analyzed with a profiling CLI tool or with a profiler ui as described in a post  ADD LINK HERE   Launch the training job as following     shell OUTDIR gs    BUCKET babyweight profiler standard JOBNAME babyweight   date  u   y m d  H M S  gsutil  m rm  rf  OUTDIR gcloud ml engine jobs submit training  JOBNAME       region us west1       module name trainer deep profiling task       package path trainer deep profiling       job dir  OUTDIR       staging bucket gs    BUCKET STAGING       scale tier STANDARD 1       runtime version  1 10               bucket  BUCKET babyweight       output dir   OUTDIR        train steps 100000          Profiler CLI 1  In order to use  profiler CLI  https   github com tensorflow tensorflow blob 9590c4c32dd4346ea5c35673336f5912c6072bf2 tensorflow core profiler README md   you need to build the profiler first   git clone https   github com tensorflow tensorflow git cd tensorflow bazel build  c opt tensorflow core profiler profiler  2  Copy dumps locally   rm  rf  tmp profiler mkdir  p  tmp profiler gsutil  m cp  r  OUTDIR profiler  tmp  3  Launch the profiler with  bazel bin tensorflow core profiler profiler   profile path  tmp profiler   ls  tmp profiler    head  1        Profiler UI You can also use a  profiler ui  https   github com tensorflow profiler ui   i e  a web interface for a tensorflow profiler  1  If you d like to install  pprof  https   github com google pprof   please follow the  installation instructions  https   github com google pprof building pprof   2  Clone the repository   git clone https   github com tensorflow profiler ui git cd profiler ui  3  Copy dumps locally   rm  rf  tmp profiler mkdir  p  tmp profiler gsutil  m cp  r  OUTDIR  MODEL profiler  tmp  4  Launch the profiler with  python ui py   profile context path  tmp profiler   ls  tmp profiler    head  1


GCP Google Cloud Platform Estimated cost to run this tutorial is 9 per day Prerequisites This tutorial uses Anthos which is on the Google Cloud Platform GCP If you don t have an account you can for 300 in free credits After signing up a GCP project and to a billing account

Answer:
# Prerequisites

## Google Cloud Platform

This tutorial uses Anthos which is on the Google Cloud Platform (GCP). If you don’t have an account, you can [sign up](https://cloud.google.com/free/) for $300 in free credits.

Estimated cost to run this tutorial is $9 per day.

After signing up, [create](https://cloud.google.com/resource-manager/docs/creating-managing-projects) a GCP project and [attach](https://cloud.google.com/billing/docs/how-to/modify-project) to a billing account.

## GitLab

This tutorial uses GitLab for code repository and for continuous integration & continuous delivery.

[Sign up](https://gitlab.com/users/sign_up) to create a GitLab account if you don’t already have one.

To grant your laptop access to make changes as this account, generate and add SSH keys to your account.

Generate SSH keys:

```bash
ssh-keygen
```

It is recommended to add a passphrase when generating new ssh keys, but for this demo you can proceed without setting one.

Copy content of `id_rsa.pub`, paste in the [key textbox](https://gitlab.com/-/profile/keys) and add key.

Create a [new public group](https://gitlab.com/groups/new) and  give it a name of choice (e.g anthos-demo).  When creating a group, gitlab assigns you a URI. Take note of the URI. All repositories/projects created during this tutorial will be under this group.

## Install and Initialize the Google Cloud SDK

Follow the Google Cloud SDK [documentation](https://cloud.google.com/sdk/docs/install) to install and configure the `gcloud` command line utility.

At the time this doc was created, some tools used in this tutorial are still in beta. To be able to utilize them, install `gcloud beta`

```bash
gcloud components install beta
```

Initialize gcloud config with the project id:

```bash
gcloud init
```

Then be sure to authorize `gcloud` to access the Cloud Platform with your Google user credentials:

```bash
gcloud auth login
```

## Install Kubectl

The `kubectl` command line utility is used to interact with the Kubernetes API Server.

Download and install `kubectl` using `gcloud`:

```bash
gcloud components install kubectl
```

Verify installation:

```bash
kubectl version --client
```

## Install nomos

The nomos command is an optional command-line tool used to interact with the Config sync operator.

Download nomos:

```bash
gcloud components install nomos
```

macOS and Linux clients should run this extra command to configure the binary to be executable.

```bash
chmod +x </path/to/nomos>
```

Move the command to a location your system searches for binaries, such as `/usr/local/bin`, or you can run the command by using its fully-qualified path.

**Environment variables**

The following environment variables are required for some of the commands in this guide

```bash
export PROJECT_ID="<project id you created earlier>"
export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
--format='value(projectNumber)')"
export USER="<user email you are using>"
export GROUP_NAME="<your gitlab group name>" # if your group name has space(s), replace with `-`
export GROUP_URI="<your gitlab group URI>"
export REGION="us-central1"
export ZONE="us-central1-c"
```

**APIs**

Enable all the APIs that are required for this guide:

```bash
gcloud services enable \
   anthos.googleapis.com \
   anthosgke.googleapis.com \
   anthosaudit.googleapis.com \
   binaryauthorization.googleapis.com \
   cloudbuild.googleapis.com \
   containerscanning.googleapis.com \
   cloudresourcemanager.googleapis.com \
   container.googleapis.com \
   gkeconnect.googleapis.com \
   gkehub.googleapis.com \
   serviceusage.googleapis.com \
   stackdriver.googleapis.com \
   monitoring.googleapis.com \
   logging.googleapis.com
```

Next: [Register GKE Clusters with Anthos](2-register-gke-clusters-with-anthos.md

Prerequisites     Google Cloud Platform  This tutorial uses Anthos which is on the Google Cloud Platform  GCP   If you don t have an account  you can  sign up  https   cloud google com free   for  300 in free credits    Estimated cost to run this tutorial is  9 per day   After signing up   create  https   cloud google com resource manager docs creating managing projects  a GCP project and  attach  https   cloud google com billing docs how to modify project  to a billing account       GitLab  This tutorial uses GitLab for code repository and for continuous integration   continuous delivery    Sign up  https   gitlab com users sign up  to create a GitLab account if you don t already have one   To grant your laptop access to make changes as this account  generate and add SSH keys to your account   Generate SSH keys       bash ssh keygen       It is recommended to add a passphrase when generating new ssh keys  but for this demo you can proceed without setting one    Copy content of  id rsa pub   paste in the  key textbox  https   gitlab com   profile keys  and add key   Create a  new public group  https   gitlab com groups new  and  give it a name of choice  e g anthos demo    When creating a group  gitlab assigns you a URI  Take note of the URI  All repositories projects created during this tutorial will be under this group       Install and Initialize the Google Cloud SDK  Follow the Google Cloud SDK  documentation  https   cloud google com sdk docs install  to install and configure the  gcloud  command line utility   At the time this doc was created  some tools used in this tutorial are still in beta  To be able to utilize them  install  gcloud beta       bash gcloud components install beta       Initialize gcloud config with the project id       bash gcloud init        Then be sure to authorize  gcloud  to access the Cloud Platform with your Google user credentials       bash gcloud auth login          Install Kubectl  The  kubectl  command line utility is used to interact with the Kubernetes API Server    Download and install  kubectl  using  gcloud        bash gcloud components install kubectl       Verify installation       bash kubectl version   client           Install nomos  The nomos command is an optional command line tool used to interact with the Config sync operator    Download nomos       bash gcloud components install nomos       macOS and Linux clients should run this extra command to configure the binary to be executable       bash chmod  x   path to nomos        Move the command to a location your system searches for binaries  such as   usr local bin   or you can run the command by using its fully qualified path     Environment variables    The following environment variables are required for some of the commands in this guide      bash export PROJECT ID   project id you created earlier   export PROJECT NUMBER    gcloud projects describe    PROJECT ID       format  value projectNumber     export USER   user email you are using   export GROUP NAME   your gitlab group name     if your group name has space s   replace with     export GROUP URI   your gitlab group URI   export REGION  us central1  export ZONE  us central1 c          APIs    Enable all the APIs that are required for this guide        bash gcloud services enable      anthos googleapis com      anthosgke googleapis com      anthosaudit googleapis com      binaryauthorization googleapis com      cloudbuild googleapis com      containerscanning googleapis com      cloudresourcemanager googleapis com      container googleapis com      gkeconnect googleapis com      gkehub googleapis com      serviceusage googleapis com      stackdriver googleapis com      monitoring googleapis com      logging googleapis com      Next   Register GKE Clusters with Anthos  2 register gke clusters with anthos md


GCP ACM is a key component of Anthos that lets you define and enforce configs including custom policies and apply it across all your infrastructure both on premises and in the cloud Set up Anthos Config Management ACM Before setting up ACM first enable the ACM feature With ACM you can set configs and policies in one repo Typically the security or operator team manages this repo Using the repo model lets developers focus on app development repo s while the security operators focus on infrastructure As long as clusters are in sync with the ACM repo changes can t be made on policies config managed by ACM except using the repo This allows enterprises to take all the advantages that come with a version control system while creating and modifying configs

Answer:
# Set up Anthos Config Management (ACM)

[Anthos Config Management](https://cloud.google.com/anthos/config-management) (ACM) is a key component of Anthos that lets you define and enforce configs, including custom policies, and apply it across all your infrastructure both on-premises and in the cloud.

With ACM, you can set configs and policies in one repo. Typically the security or operator team manages this repo. Using the repo model lets developers focus on app development repo(s) while the security/operators focus on infrastructure. As long as clusters are in sync with the ACM repo, changes can’t be made on policies/config managed by ACM except using the repo. This allows enterprises to take all the advantages that come with a version control system while creating and modifying configs. [Learn more](https://cloud.google.com/anthos-config-management/docs/concepts).

Before setting up ACM, first enable the ACM feature:

```bash
gcloud alpha container hub config-management enable
```

## Create GitLab repo/project

Click on the [GitLab $GROUP_NAME group](https://gitlab.com/dashboard/groups) you created earlier and create a new blank project called ACM. Make it public:

![alt_text](images/create-blank-project.png "Create blank project")

Clone the repo locally and use nomos to create the [repo structure](https://cloud.google.com/kubernetes-engine/docs/add-on/config-sync/concepts/repo) that allows [Config Sync](https://cloud.google.com/kubernetes-engine/docs/add-on/config-sync/overview) to read from the repo:

```bash
cd ~
mkdir $GROUP_NAME
cd $GROUP_NAME/
git clone git@gitlab.com:$GROUP_NAME/acm.git
cd acm/
git switch -c main
nomos init
```

To know more about the functions of the different directories created by `nomos init `you can read the [repo structure](https://cloud.google.com/kubernetes-engine/docs/add-on/config-sync/concepts/repo) documentation.

## Deploy config sync operator to clusters

The [Config Sync Operator](https://cloud.google.com/kubernetes-engine/docs/add-on/config-sync/how-to/installing#git-creds-secret) is a controller that manages Config Sync in a Kubernetes cluster.

[Download](https://cloud.google.com/anthos-config-management/downloads) the operator and deploy to your clusters:

```bash
cd ~/$GROUP_NAME/acm
mkdir setup
cd setup/
gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml

for i in "dev" "prod"; do
  gcloud container clusters get-credentials ${i} --zone=$ZONE
  kubectl apply -f config-management-operator.yaml
done
```

## Configure operator

To configure the behavior of Config sync, create 2 configuration files `config-management-dev.yaml `for the dev cluster and `config-management-prod.yaml` for the prod cluster:

```bash
cat > config-management-dev.yaml << EOF
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  clusterName: dev
  git:
    syncRepo: https://gitlab.com/$GROUP_URI/acm.git
    syncBranch: dev
    secretType: none
  policyController:
    enabled: true
EOF

cat > config-management-prod.yaml << EOF
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  clusterName: prod
  git:
    syncRepo: https://gitlab.com/$GROUP_URI/acm.git
    syncBranch: main
    secretType: none
  policyController:
    enabled: true
EOF
```

Note: Notice the syncBranch values. secretType is set to none because the repo is public. If repo isn’t public grant operator access by following these [steps](https://cloud.google.com/kubernetes-engine/docs/add-on/config-sync/how-to/installing#git-creds-secret).

## ClusterSelectors and Namespaces

[ClusterSelectors](https://cloud.google.com/kubernetes-engine/docs/add-on/config-sync/how-to/clusterselectors) and [namespaces](https://cloud.google.com/kubernetes-engine/docs/add-on/config-sync/how-to/namespace-scoped-objects) are ways of grouping to apply configs on a subset of our infrastructure. The ACM repo is where all clusterselectors and namespaces are defined and applied

Navigate to clusterregistry/ in acm repo:

```bash
cd ~/$GROUP_NAME/acm/clusterregistry
```

Create prod and dev cluster selectors:

```bash
cat > dev-cluster-selector.yaml << EOF
kind: Cluster
apiVersion: clusterregistry.k8s.io/v1alpha1
metadata:
 name: dev
 labels:
   environment: dev
---
kind: ClusterSelector
apiVersion: configmanagement.gke.io/v1
metadata:
 name: dev-cluster-selector
spec:
 selector:
   matchLabels:
     environment: dev

EOF

cat > prod-cluster-selector.yaml << EOF
kind: Cluster
apiVersion: clusterregistry.k8s.io/v1alpha1
metadata:
 name: prod
 labels:
   environment: prod
---
kind: ClusterSelector
apiVersion: configmanagement.gke.io/v1
metadata:
 name: prod-cluster-selector
spec:
 selector:
   matchLabels:
     environment: prod
EOF
```

Create 3 namespaces dev, stage and prod and set up so that dev and stage namespaces deploy to the dev cluster and prod deploys to prod cluster:

```bash
cd ~/$GROUP_NAME/acm/namespaces
mkdir dev
cd dev
cat > namespace.yaml << EOF
apiVersion: v1
kind: Namespace
metadata:
 name: dev
 annotations:
   configmanagement.gke.io/cluster-selector: dev-cluster-selector
EOF

cd ..
mkdir stage
cd stage
cat > namespace.yaml << EOF
apiVersion: v1
kind: Namespace
metadata:
 name: stage
 annotations:
   configmanagement.gke.io/cluster-selector: dev-cluster-selector
EOF

cd ..
mkdir prod
cd prod
cat > namespace.yaml << EOF
apiVersion: v1
kind: Namespace
metadata:
 name: prod
 annotations:
   configmanagement.gke.io/cluster-selector: prod-cluster-selector
EOF
```

## Policy constraint

Lastly, we’ll take advantage of the policy control feature of ACM and create a policy. [Policy controller](https://cloud.google.com/anthos-config-management/docs/concepts/policy-controller) is used to check, audit and enforce your clusters’ compliance with policies that may be related to security, regulations or arbitrary business rules.

In this tutorial we’ll create a no privileged container constraint and apply it to the prod namespace. Notice we set policycontroller to true in `config-management-prod.yaml `earlier. This will enable this policy to be enforced in our clusters.

Create `constraint-restrict-privileged-container.yaml` in `cluster/` :

```bash
cd ~/$GROUP_NAME/acm/cluster

cat > constraint-restrict-privileged-container.yaml << EOF
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
 name: noprivilegedcontainer
 annotations:
    configmanagement.gke.io/cluster-selector: prod-cluster-selector
spec:
 crd:
   spec:
     names:
       kind: NoPrivilegedContainer
 targets:
   - target: admission.k8s.gatekeeper.sh
     rego: |
       package noprivileged
       violation[{"msg": msg, "details": {}}] {
           c := input_containers[_]
           c.securityContext.privileged
           msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext])
       }
       input_containers[c] {
           c := input.review.object.spec.containers[_]
       }
       input_containers[c] {
           c := input.review.object.spec.initContainers[_]
       }
       input_containers[c] {
           c := input.review.object.spec.template.spec.containers[_]
       }
       input_containers[c] {
           c := input.review.object.spec.template.spec.initContainers[_]
       }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: NoPrivilegedContainer
metadata:
 name: no-privileged-container
 annotations:
    configmanagement.gke.io/cluster-selector: prod-cluster-selector
spec:
 enforcementAction: dryrun
 match:
   kinds:
     - apiGroups: ["*"]
       kinds: ["Deployment", "Pod"]
EOF
```

## Push changes to remote

Now that we have made these changes locally, let’s push these changes to the remote repo so the clusters can read from it and configure itself:

Push changes to remote:

```bash
git add -A
git commit -m "Set up ACM"
git push -u origin main
```

Since the dev cluster is configured to sync with the dev branch, create a new branch called `dev`  from the `main` branch by clicking the “+” sign in the repo page.

Also create a branch called dev in your local and switch to this branch

```bash
git checkout dev
```

 Apply the configuration:

```bash
cd ~/$GROUP_NAME/acm/setup

for i in "dev" "prod"; do
   gcloud container clusters get-credentials ${i} \
       --zone=$ZONE
   kubectl apply -f config-management-${i}.yaml
done
```

Verify the configuration for both dev and prod clusters:

```bash
for i in "dev" "prod"; do
   gcloud container clusters get-credentials ${i}
   kubectl -n kube-system get pods | grep config-management
done
```

You should see a response like below for both of your clusters:

```bash
config-management-operator-59455ffc4-c6nvp          1/1       Running         4m52s
```

Confirm your clusters are synced from the [console](https://console.cloud.google.com/anthos/config_management) or run:

```bash
nomos status
```

A status of `Pending` or `Synced` means your installation is fine

Next: [CICD with Anthos and Gitlab](4-cicd-with-anthos-and-gitlab.md

Set up Anthos Config Management  ACM    Anthos Config Management  https   cloud google com anthos config management   ACM  is a key component of Anthos that lets you define and enforce configs  including custom policies  and apply it across all your infrastructure both on premises and in the cloud   With ACM  you can set configs and policies in one repo  Typically the security or operator team manages this repo  Using the repo model lets developers focus on app development repo s  while the security operators focus on infrastructure  As long as clusters are in sync with the ACM repo  changes can t be made on policies config managed by ACM except using the repo  This allows enterprises to take all the advantages that come with a version control system while creating and modifying configs   Learn more  https   cloud google com anthos config management docs concepts    Before setting up ACM  first enable the ACM feature       bash gcloud alpha container hub config management enable           Create GitLab repo project  Click on the  GitLab  GROUP NAME group  https   gitlab com dashboard groups  you created earlier and create a new blank project called ACM  Make it public      alt text  images create blank project png  Create blank project     Clone the repo locally and use nomos to create the  repo structure  https   cloud google com kubernetes engine docs add on config sync concepts repo  that allows  Config Sync  https   cloud google com kubernetes engine docs add on config sync overview  to read from the repo       bash cd   mkdir  GROUP NAME cd  GROUP NAME  git clone git gitlab com  GROUP NAME acm git cd acm  git switch  c main nomos init       To know more about the functions of the different directories created by  nomos init  you can read the  repo structure  https   cloud google com kubernetes engine docs add on config sync concepts repo  documentation       Deploy config sync operator to clusters  The  Config Sync Operator  https   cloud google com kubernetes engine docs add on config sync how to installing git creds secret  is a controller that manages Config Sync in a Kubernetes cluster    Download  https   cloud google com anthos config management downloads  the operator and deploy to your clusters       bash cd    GROUP NAME acm mkdir setup cd setup  gsutil cp gs   config management release released latest config management operator yaml config management operator yaml  for i in  dev   prod   do   gcloud container clusters get credentials   i    zone  ZONE   kubectl apply  f config management operator yaml done           Configure operator  To configure the behavior of Config sync  create 2 configuration files  config management dev yaml  for the dev cluster and  config management prod yaml  for the prod cluster       bash cat   config management dev yaml    EOF apiVersion  configmanagement gke io v1 kind  ConfigManagement metadata    name  config management spec    clusterName  dev   git      syncRepo  https   gitlab com  GROUP URI acm git     syncBranch  dev     secretType  none   policyController      enabled  true EOF  cat   config management prod yaml    EOF apiVersion  configmanagement gke io v1 kind  ConfigManagement metadata    name  config management spec    clusterName  prod   git      syncRepo  https   gitlab com  GROUP URI acm git     syncBranch  main     secretType  none   policyController      enabled  true EOF       Note  Notice the syncBranch values  secretType is set to none because the repo is public  If repo isn t public grant operator access by following these  steps  https   cloud google com kubernetes engine docs add on config sync how to installing git creds secret        ClusterSelectors and Namespaces   ClusterSelectors  https   cloud google com kubernetes engine docs add on config sync how to clusterselectors  and  namespaces  https   cloud google com kubernetes engine docs add on config sync how to namespace scoped objects  are ways of grouping to apply configs on a subset of our infrastructure  The ACM repo is where all clusterselectors and namespaces are defined and applied  Navigate to clusterregistry  in acm repo       bash cd    GROUP NAME acm clusterregistry       Create prod and dev cluster selectors       bash cat   dev cluster selector yaml    EOF kind  Cluster apiVersion  clusterregistry k8s io v1alpha1 metadata   name  dev  labels     environment  dev     kind  ClusterSelector apiVersion  configmanagement gke io v1 metadata   name  dev cluster selector spec   selector     matchLabels       environment  dev  EOF  cat   prod cluster selector yaml    EOF kind  Cluster apiVersion  clusterregistry k8s io v1alpha1 metadata   name  prod  labels     environment  prod     kind  ClusterSelector apiVersion  configmanagement gke io v1 metadata   name  prod cluster selector spec   selector     matchLabels       environment  prod EOF       Create 3 namespaces dev  stage and prod and set up so that dev and stage namespaces deploy to the dev cluster and prod deploys to prod cluster       bash cd    GROUP NAME acm namespaces mkdir dev cd dev cat   namespace yaml    EOF apiVersion  v1 kind  Namespace metadata   name  dev  annotations     configmanagement gke io cluster selector  dev cluster selector EOF  cd    mkdir stage cd stage cat   namespace yaml    EOF apiVersion  v1 kind  Namespace metadata   name  stage  annotations     configmanagement gke io cluster selector  dev cluster selector EOF  cd    mkdir prod cd prod cat   namespace yaml    EOF apiVersion  v1 kind  Namespace metadata   name  prod  annotations     configmanagement gke io cluster selector  prod cluster selector EOF           Policy constraint  Lastly  we ll take advantage of the policy control feature of ACM and create a policy   Policy controller  https   cloud google com anthos config management docs concepts policy controller  is used to check  audit and enforce your clusters  compliance with policies that may be related to security  regulations or arbitrary business rules    In this tutorial we ll create a no privileged container constraint and apply it to the prod namespace  Notice we set policycontroller to true in  config management prod yaml  earlier  This will enable this policy to be enforced in our clusters   Create  constraint restrict privileged container yaml  in  cluster          bash cd    GROUP NAME acm cluster  cat   constraint restrict privileged container yaml    EOF apiVersion  templates gatekeeper sh v1beta1 kind  ConstraintTemplate metadata   name  noprivilegedcontainer  annotations      configmanagement gke io cluster selector  prod cluster selector spec   crd     spec       names         kind  NoPrivilegedContainer  targets       target  admission k8s gatekeeper sh      rego           package noprivileged        violation   msg   msg   details                     c    input containers               c securityContext privileged            msg    sprintf  Privileged container is not allowed   v  securityContext   v    c name  c securityContext                   input containers c               c    input review object spec containers                    input containers c               c    input review object spec initContainers                    input containers c               c    input review object spec template spec containers                    input containers c               c    input review object spec template spec initContainers                 apiVersion  constraints gatekeeper sh v1beta1 kind  NoPrivilegedContainer metadata   name  no privileged container  annotations      configmanagement gke io cluster selector  prod cluster selector spec   enforcementAction  dryrun  match     kinds         apiGroups               kinds    Deployment    Pod   EOF           Push changes to remote  Now that we have made these changes locally  let s push these changes to the remote repo so the clusters can read from it and configure itself   Push changes to remote       bash git add  A git commit  m  Set up ACM  git push  u origin main       Since the dev cluster is configured to sync with the dev branch  create a new branch called  dev   from the  main  branch by clicking the     sign in the repo page   Also create a branch called dev in your local and switch to this branch      bash git checkout dev        Apply the configuration       bash cd    GROUP NAME acm setup  for i in  dev   prod   do    gcloud container clusters get credentials   i             zone  ZONE    kubectl apply  f config management   i  yaml done      Verify the configuration for both dev and prod clusters       bash for i in  dev   prod   do    gcloud container clusters get credentials   i     kubectl  n kube system get pods   grep config management done       You should see a response like below for both of your clusters       bash config management operator 59455ffc4 c6nvp          1 1       Running         4m52s        Confirm your clusters are synced from the  console  https   console cloud google com anthos config management  or run       bash nomos status       A status of  Pending  or  Synced  means your installation is fine   Next   CICD with Anthos and Gitlab  4 cicd with anthos and gitlab md