Laura Liparulo's blog

Category: CONTAINERS

Kubernetes – Getting ready for CKAD Certification

Posted on
Posted inCONTAINERS , Kubernetes

Although you can refer to the official Kubernetes during the exam, you need to be very fast at completing the tasks.

So it´s important to use aliases and shortcuts, take advantage of the documentation in the CLI (like “kubectl explain” or “–help”) and understand how to update resources.

CREATE ALIASES AND SHORTCUTS

The “k” alias for “kubectl” is provided. But to spare time, once you are logged in the exam shell, you might additionally need to define other things, like the context switching:

$ alias kn='kubectl config set-context --current --namespace

$ export now=”--force --grace-period 0”

$ export do=“--dry-run=client -o yaml”

This way, creating a yaml for a pod file becomes a lot easier:

$ k run pod1 --image=httpd:2.4.31-alpine --labels="test=true,tenancy=test" --env tempdir=/tmp $do > pod.yaml

This allows you to edit the file before creating the objects with “k create -f” or “k apply -f“:

$ k create -f pod1.yaml

USE THE CLI DOCS RATHER THAN WEB PAGES

For example
$ kubectl explain pods.spec.tolerations

UPDATE DEPLOYMENTS QUICKLY

After creating a deployment with replicas:

$ kubectl create deploy httpd-frontend --image=httpd:2.4-alpine

you can update the number of replica live :

$ k scale --replicas 6 deployment httpd-frontend

And also, for example, add resources limits:

$ k set resources deploy httpd-frontend --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

You can add new labels, like:

$ k label deploy httpd-frontend tenancy=prod

Or ovewrite an existing one:

$ k label deploy httpd-frontend app=frontend --overwrite

ADD environment variables:

$ kubectl set env deployment/registry STORAGE_DIR=/local

Or even directly from a config map or a secret
$ kubectl set env deployment nginx --from=configmap/vars --keys="var1,var2"
$ kubectl set env deployment nginx --from=secret/passwords --keys="pass1

Let´s try for example:

$ k set env deploy httpd-frontend --env var3=344343

Once you have set the environment variable, the pods are terminated and recreated.

So you need to pick a new one to check if the environmente varialbe is there:

if you update the image:

$ kubectl set image deploy httpd-frontend httpd=httpd:2.6-alpine

Afterwards you can add an annotation to the current deployment, to see the information in the rollout history:

$ kubectl annotate deploy httpd-frontend kubernetes.io/change-cause='update image'

EXPOSING A DEPLOYMENT OR POD (SERVICE CREATION)

Services can also be created with commands, like:

$ kubectl expose deploy redis -n marketing --type=NodePort --port=6379 --name=msg-svc

$ kubectl expose pod redis --port=6379 --target-port=6379 --name=redis-service

this will make Kubernetes create a service for you deployment.

You can also use “create service”:

$ kubectl create service clusterip my-cs --clusterip="None"

PASSING A COMMAND TO A NEW JOB

$ k create job njob –-image=busybox:1.31.0 $do > job.yaml –- sh -c “sleep 2 && echo done”

POD CPU USAGE

You will be asked to check which pods is consuming the most CPU. You can check it out with “top”:

$ k top <podname>

CREATE A VOLUME CONFIGURATION IN A POD

Although deprecated, if you only need a pod with volumes, using the “-o yaml” option will add one for you, that you can later edit.

k run nginx2 --image=nginx -o yaml > lab5.yaml

Of course there´s a lot of lines to clean up, but if you are fast with vim you can make it.

this will run a pod, but you can delete it and keep the file for creating what you need.

RUN NEW PODS WITH CONFIGURATION ELEMENTS

You add other stuff in your configuratio in the CLI directly, like:

  • labels
  • environment variables
  • command for your pod
  • service account

k run mypod --image=busybox --labels="tier=msg,review=none" --env VAR1=hello --env VAR2=world –serviceaccount=mysa -o yaml > p.yaml --command -- sh -c "while true; do date; sleep 2; done"

Then you just need to delete the pod “mypod”, edit the yaml file (deleting the “managedFields” sections) and create the pod you need.

This is much better than copying and pasting codes, as you don´t have indentation issues. And you can quickly find the command options at:

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

On the right side of the docs you always have examples:

CREATE VS RUN

You can use “kubectl run” to create pods.

$ kubectl run alpaca-prod --image=gcr.io/kuar-demo/kuard-amd64:blue --labels="ver=1,app=alpaca,env=prod"

But if you want to create a deployment you can´t use run. You will need to use “kubectl create”:

$ kubectl create deploy httpd-frontend --image=httpd:2.4-alpine

MAKE SURE THINGS WORK!

Check things are running with “kubectl get”, or describe:

$ K describe po messaging | grep -C 5 -I labels

Pipe commands with grep to avoid scrolling too much. you won´t have time!

Access pods to run commands in the bash:
$ kubectl exec -it sidecar-pod -c sidecar– /bin/sh

And curl service endpoints!

JOBS & CRONJOBS

To create a job imperatively, pass the command at the end:

$ K create job neb-new-job –-image=busybox:1.31.0 $do > /opt/course/3/job.yaml –- sh -c “sleep 2 && echo done”

To create a cronjob, you generally need to pass the schedule parameter

$ kubectl create cronjob dice –-image=kodecloud/throw dice –-schedule=”*/1 * * * *”

You can as well create a job out of a cronjob:

$ kubectl create job test-job --from=cronjob/a-cronjob

TEST YOUR SERVICES

You should be able to curl your service:

A temporary pod with the nginx:alpine immage running curl would be helpful:

$ kubectl run tmp --restart=Never --rm -i --image=nginx:alpine -- curl -m 5 manager-api-svc:4444

If you can´t curl this way, probably the service is malconfigured..and endpoint missing.

Kubernetes – Namespaces

Posted on
Posted inCONTAINERS , Kubernetes

You can create a single physical cluster as a set of virtual clusters by using namespaces.

After creating you first namespace, for example “my-space”, you can see that, as default, you also have a default namespace as well other others used by kubernetes under the hood:

Namespaces in Kubernetes allow you to group workloads and resources together.

It´s very useful if you have a lot of objects and you want to search or execute operations on some of them according to the purpose.

Namespace don´t provide isolation. By default, pods can access other pods and services in ohter namespaces, but you can isolate them by using network policies too. And also apply resource quotas to them.

You can´t assign nodes and persistent volumes to the same namespaces. This means, for example, that pods from different namespaces can you the same persistence storage.

If you omit the namespace (by using “-n myspace” or “–namespace myspace”), kubernetes will use the default one.

Make sure that users that can operate on a dedicated namespace don’t have access to the default namespace. Otherwise, every time they forget to specify a namespace, they’ll operate quietly on the default namespace.

The best way to avoid this situation is to “seal” the namespace and require different users and credentials for each namespace, like using users and root iwith sudo on your machine.

If you are planning to work with the same namespace for a while, you can defne a context, so you don’t have to keep typing --namespace=ns for every command:

$ kubectl config set-context dev-context --namespace=my-space --user=default --cluster=default
Context "dev-context" created.
$ kubectl config use-context dev-context
Switched to context "dev-context".

it´s good to split complex systems into smaller groups. For example, in a multi-tenant environment (prod-dev-test). And namespaces can help you!

Kubernetes – using the patch command for updates

Posted on
Posted incloud , CONTAINERS , Kubernetes

What´s really cool about kubernetes is that you can update your workloads live.

One kubectl command that definetely might make you achieve things faster is the patch command.

Let´s say you want to add a container to the following deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dep-to-update
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: ngxinx-container
        image: nginx

To add another container you can create a patch file called “redis-patch.yaml”:

spec:
  template:
    spec:
      containers:
      - name: patch-demo-ctr-2
        image: redis

All you need to do then is executing a command like:

$ kubectl patch deployment dep-to-update --patch-file redis-patch.yaml

After running this command, kubernetes will redeploy the updated version.

If you run “k describe pod dep-to-update-3829238kdls” you will see that both containers are created:

If you access the dep-to-update deployment yaml file, you can now see both containers:

Don´t forget to put “spec > template > spec > containers” in the patch file.

The following file won´t be patched:

    spec:
      containers:
      - name: patch-demo-ctr-2
        image: redis

Kubernetes – Pods Security Context

Posted on
Posted incloud , CONTAINERS , Kubernetes

A security context allows to control the privileges and access settings for a pod or container.

It allows you to define:

  • permissions to access an object (Discretionary Access Control)
  • security labels (Security Enhanced Linux)
  • privileged and unprivileged users
  • Linux capabilities
  • privilege escalation allowance
  • etc.

As default the containers run the processes as root. This is possible thanks to the container isolation principle.

However, in some circumstances, you might need to use specific rights according to your needs.

If you want to define a configuration for the whole pod, you can edit the security Context section under pod.spec.

In the container section, you also the opportunity to edit it under spec.containers, as you can see in the docs.

The following example shows you both the settings:


apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx-secure
  name: nginx-secure
  namespace: default
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1001
    supplementalGroups:
    - 1002
    - 1003
  containers:
  - image: nginx
    name: nginx-secure
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: false
  volumes:
  - name: sec-ctx-vol
    # This AWS EBS volume must already exist.
    awsElasticBlockStore:
      volumeID: "3232323"
      fsType: ext4

Kubernetes – Running from a custom Docker image

Posted on
Posted inCONTAINERS , DOCKER , Kubernetes

As I am getting ready for CKA exam, I will show you how to run a pod on Kubernetes starting from the a Dockerfile.

Let´s say we want to create a Node.Js simple server, a simpe app.js file.

const http = require('http');
const os = require('os');

console.log("My node js server is starting...");

var handler = function(request, response) {
  console.log("Received request from " + request.connection.remoteAddress);
  response.writeHead(200);
  response.end("You've hit " + os.hostname() + "\n");
};

var www = http.createServer(handler);
www.listen(8080);

Once we have the app.js file, we can create a Dockerfile too:

FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node", "app.js"]

Then we can build the image:

docker build -t node-js-server-image .

Once we have created the image, we need to login to Docker Hub with the “docker login” command, then tag and push our image:

$ docker login

$ docker tag node-js-server-image lauraliparulo/node-js-server-image

$ docker push lauraliparulo/node-js-server-image

Then you can use the image to create a kubernetes pod

$ kubectl run nodejs --image=lauraliparulo/node-js-server-image --port=8080

With “kubectl describe pod node-js” we can find the IP of the exposed pod:

Then we can check the content with “curl”:

Docker – hello world example

Posted on
Posted inCONTAINERS , DOCKER

To run your first docker container, you can simply use a busybox image. With a single command, docker will download and execute the application inside a n isolated container:

> docker run busybox echo "Hello world"

As the image was not present on the machine, Docker pulled it from the Docker Hub Registry.

Another way is to create a simple two lines Dockerfile, like:

FROM alpine
CMD ["/bin/sh", "-c", "echo 'hello world'"]

As you can see, the starting point (with “FROM”) is an alpine base image. Then it´s just a matter of running an echo command in it.
From the folder where the Dockerfile is stored, invoke:

docker build -t helloworld .

And you get in the console:

Run:  
docker run hello-world
And you will see again:
hello world
As you can see, docker pulls the base alpine image  (6dbb9cc54074)
You can check the history of the container:
docker history hello-world

Or inspect it:

docker inspect f5d273aa2dcb

And finally remove it:

docker rmi -f f5d237aa2dcb

Kubernetes – Imperative Job creation

Posted on
Posted inCONTAINERS , Kubernetes , Programming

Let´s create a job the imperative way, by using the docker whalesay image:

kubectl create job whalesay --image=docker/whalesay --dry-run=client -o yaml > job.yaml -- cowsay I am going to ace CKAD!

We are using the “dry-run” option to create a yaml manifest without creating the job.

In the last part of the command with add a command for the container, that will be put directly in the manifest.

Once the file is created, we can add parameters like completions, parallelism and backoffLimit under the spec.template section, like this:

Then we need to create the job, by running:

kubectl create -f job.yaml -n <your-namespace>

After a while we can see the pods have been run and completed:

If you inspect the log of one of the pod, you can see the funny whale comics:

kubectl logs whalesay-7h27f

MORE ABOUT JOBS

Specifying the restartPolicy is mandatory for a Job.

Notice that:

  • a job is persisted and survives cluster restarts
  • a completed job is kept for tracking purposes

Kubernetes – Resources limits

Posted on
Posted incloud , CONTAINERS , Kubernetes

As containers might be consuming too many compressible resources, such as CPU or network bandwidth. And also incompressible resources, like memory.

Luckily, Kubernetes can access and control the linux cgroups CPU and memory limitations for each pod.

Kubernetes distinguish between “requests” and “limits”, very much like soft/hard limits in linux.

Requests specify the minimum amount of resources that are needed, whereas limits define the maximum amount the containers can grow up to. This means that limits are supposed to be larger than the requests.

The kubernetes schedules assings a pod to a node according to the requests value: only the nodes that can have enough capacity to accomodate the pods are considered for scheduling.

So, basically, the requests sections determines where a Pod will be scheduled.

HOW TO CONFIGURE RESOURCES

You can add the specification to your deployment or pod (?) directly with the “set” command:

$ kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

This will awork as a live update and will assign the same values to each container in your deployment.

Your pods will be recreated with the new values.

Resources are always defined in the container section:

apiVersion: v1
kind: Pod
metadata:
  name: random-generator
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
    resources:
      requests:                         
        cpu: 100m
        memory: 100Mi
      limits:                           
        cpu: 200m
        memory: 200Mi

If you omit the resources configuration, default values will be added.

In this case a best-effort strategy will be put in place, which means the pods will have the lowest priority and be killed first, where the node runs out of resources.

You won´t see any entry in the yaml manifest:

Kubernetes – Multi-Containers Design Pattern

Posted on
Posted incloud , CONTAINERS , Kubernetes

A multi-container pod can be defined by the following structural design patterns:

  • init container
  • sidecar
  • ambassador
  • adapter

The are basically best practices and distributed system design patterns.

They contribute to achieving separation of concerns.

INIT CONTAINERS
Init containers are additional containers used to complete tasks before the regular containers are started in a pod.

For example:

spec:
  template:
    metadata:
      labels:
         app: flask
    spec:
      containers:
      - name: flask
        image: quay.io/kubernetes-for-developers/flask:0.2.0
        ports:
        - containerPort: 5000
        envFrom:
        - configMapRef:
           name: flask-config
        volumeMounts:
          - name: config
            mountPath: /etc/flask-config
            readOnly: true
      volumes:
        - name: config
          configMap:
            name: flask-config
      initContainers:
      - name: init-myservice
        image: busybox
        command: ['sh', '-c', 'until nslookup redis-master; do echo waiting for redis; sleep 2; done;']

SIDECAR

A sidecar container is meant to assist the main container with additional functionalities, like intercepting the inbound traffic, or aggregating logs.

The main application container is unaware of the sidecar container.

Let´s consider, for example, a central logging agent. 

      containers:
      - name: cleaner-con
        image: bash:5.0.11
        args: ['bash', '-c', 'while true; do echo `date`: "remove random file" >> /var/log/cleaner/cleaner.log; sleep 1; done']
        volumeMounts:
        - name: logs
          mountPath: /var/log/cleaner
      - name: logger-con                                                
        image: busybox:1.31.0                                           
        command: ["sh", "-c", "tail -f /var/log/cleaner/cleaner.log"]  
        volumeMounts:                                                   
        - name: logs                                                    
          mountPath: /var/log/cleaner

In the code about the sidecar container is called “logger-con”

The sidecar container will send the logs to a central logging service, for aggregation purporse.

This would have a huge benefit, as your changes to your central logging policy (for example, a new provider) will only affected the dedicates side container.

This would prevent you from breaking the application containers while performing logging updates.

ADAPTER

If the sidecar container is meant to adapt data for the container, it´s called an adapter.

The adapter pattern is about standardizing output from the main application container.

Consider the case of a service that is being rolled out incrementally: it may generate reports in a format that doesn’t conform to the previous version.

Other services and applications that consume that output haven’t been upgraded yet. An adapter container can be deployed in the same pod with the new application container and massage the output to match the old version until all consumers have been upgraded.

The adapter container shares the filesystem with the main application container, so it can watch the local filesystem, and whenever the new application writes something, it immediately adapts it.

AMBASSADOR

It´s a container calling other containers on behalf of the main container.

This allows to have several ambassadors according to protocols or different database types.

For example you might have a Database ambassador for MySql and another one for oracle-db.

It´s a specialization of a sidecar, responsible for hiding complexity and providing interfaces.

Kubernetes – updating strategies

Posted on
Posted incloud , CONTAINERS , Kubernetes

The applications you deploy on Kubernetes will often need updates. Rather than deploying them from scratch again, you can take advantage of different update strategies.

A live update is not trivial, especially if you have interactions between different parts of the system, inter-dependecies among pods, etc.

in many cases you need to keep your applications running also while performing maintenance and upgrading tasks.  After all, it´s what Kubernetes is designed for: providing high availability and reliability.

There ae several updating strategies like:

  • rolling update
  • blue-green deployments
  • canary deployments

ROLLING UPDATE

With a rolling update strategy, Kubernetes creates a new ReplicaSet, replacing the Replicas one by one. the cluster will be running current and new components at the same time. If the components are backward-compatible, it´s a lot easier of course.

Two strategies possible:

– Recreate , which means killing all the pods before creating the new ones

– RollingUpdate – which guarantees the availability of the service during the update

RollingUpdate is the default strategy and can be tuned to guarantee a minimal and maximal amount of pods available during the update by using the options “maxSurge” and “maxUnavailable”.

The way an update is handled can be defined as a strategy in the spec.strategy section of the deployment manifest, like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: random-generator
spec:
  replicas: 3                            
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                        
      maxUnavailable: 1                  
    selector:
      matchLabels:
        app: random-generator
    template:
      metadata:
        labels:
          app: random-generator
      spec:
        containers:
        - image: k8spatterns/random-generator:1.0
            name: random-generator
          readinessProbe:                
            exec:
              command: [ "stat", "/random-generator-ready" ]

Notice that we can use both integer and percentages as value in the options. It means that the following is also valid:

strategy:

  rollingUpdate:

    maxSurge: 25%

    maxUnavailable: 50%

  type: RollingUpdate

You might have to create a temporary compatibility layer, while doing your updates. So Rolling updates is not the answer to more complex architectures.

BLUE-GREEN

It consists of preparing a full new version deployment for the whole production environment. So you have a blue old productive environment and a brand new green one ready to be put in place. If you have storage data to carry with you in the new version, you might need additional efforts.

The green deployment doesn´t serve any request, until the staff is confident that it will be working properly. That´s when the blue deployment will be killed and replaced.

Such strategy can be aided by extensions like a Service Mesh or Knative.

A drawback is that it takes double capacity.

CANARY DEPLOYMENT

A canary deployment is a new version deployment that is only submitted to a subset of users for testing purposes. Only when the subset of new instances will be satisfying, the whole deployment will be replaced.

This technique can be implemented by creating a new ReplicaSet for the new container version, by using a new deployment, with few replicas.



			

		

	







	
	



			
		

		

	

	            

                

                    

                        

							We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.							                        

                    

                    


                        

							                                

                                    Cookies settings
                                

								                                

                                    Accept
                                

								                        


                    

                

            

			            

                

                    

                    

                    

						                        

                            Privacy & Cookie policy
                            
                        

                        

                            

								Privacy & Cookies policy                            

                            
Cookies list

                        

                        

                            

                                
                                

                                    Cookie name
                                    Active
                                

								                                
                            

                            

								


Privacy Policy






What information do we collect?

We collect information from you when you register on our site or place an order.

When ordering or registering on our site, as appropriate, you may be asked to enter your: name, e-mail address or mailing address.

What do we use your information for?

Any of the information we collect from you may be used in one of the following ways:

To personalize your experience
(your information helps us to better respond to your individual needs)
To improve our website
(we continually strive to improve our website offerings based on the information and feedback we receive from you)
To improve customer service
(your information helps us to more effectively respond to your customer service requests and support needs)

To process transactions
Your information, whether public or private, will not be sold, exchanged, transferred, or given to any other company for any reason whatsoever, without your consent, other than for the express purpose of delivering the purchased product or service requested.

To administer a contest, promotion, survey or other site feature

To send periodic emails
The email address you provide for order processing, will only be used to send you information and updates pertaining to your order.

How do we protect your information?

We implement a variety of security measures to maintain the safety of your personal information when you place an order or enter, submit, or access your personal information.

We offer the use of a secure server. All supplied sensitive/credit information is transmitted via Secure Socket Layer (SSL) technology and then encrypted into our Payment gateway providers database only to be accessible by those authorized with special access rights to such systems, and are required to?keep the information confidential.

After a transaction, your private information (credit cards, social security numbers, financials, etc.) will not be kept on file for more than 60 days.

Do we use cookies?

Yes (Cookies are small files that a site or its service provider transfers to your computers hard drive through your Web browser (if you allow) that enables the sites or service providers systems to recognize your browser and capture and remember certain information

We use cookies to help us remember and process the items in your shopping cart, understand and save your preferences for future visits, keep track of advertisements and compile aggregate data about site traffic and site interaction so that we can offer better site experiences and tools in the future. We may contract with third-party service providers to assist us in better understanding our site visitors. These service providers are not permitted to use the information collected on our behalf except to help us conduct and improve our business.

If you prefer, you can choose to have your computer warn you each time a cookie is being sent, or you can choose to turn off all cookies via your browser settings. Like most websites, if you turn your cookies off, some of our services may not function properly. However, you can still place orders by contacting customer service.

Google Analytics

We use Google Analytics on our sites for anonymous reporting of site usage and for advertising on the site. If you would like to opt-out of Google Analytics monitoring your behaviour on our sites please use this link (https://tools.google.com/dlpage/gaoptout/)

Do we disclose any information to outside parties?

We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our website, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety. However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses.

Registration

The minimum information we need to register you is your name, email address and a password. We will ask you more questions for different services, including sales promotions. Unless we say otherwise, you have to answer all the registration questions.

We may also ask some other, voluntary questions during registration for certain services (for example, professional networks) so we can gain a clearer understanding of who you are. This also allows us to personalise services for you.

To assist us in our marketing, in addition to the data that you provide to us if you register, we may also obtain data from trusted third parties to help us understand what you might be interested in. This ‘profiling’ information is produced from a variety of sources, including publicly available data (such as the electoral roll) or from sources such as surveys and polls where you have given your permission for your data to be shared. You can choose not to have such data shared with the Guardian from these sources by logging into your account and changing the settings in the privacy section.

After you have registered, and with your permission, we may send you emails we think may interest you. Newsletters may be personalised based on what you have been reading on theguardian.com. At any time you can decide not to receive these emails and will be able to ‘unsubscribe’.

Logging in using social networking credentials

If you log-in to our sites using a Facebook log-in, you are granting permission to Facebook to share your user details with us. This will include your name, email address, date of birth and location which will then be used to form a Guardian identity. You can also use your picture from Facebook as part of your profile. This will also allow us and Facebook to share your, networks, user ID and any other information you choose to share according to your Facebook account settings. If you remove the Guardian app from your Facebook settings, we will no longer have access to this information.

If you log-in to our sites using a Google log-in, you grant permission to Google to share your user details with us. This will include your name, email address, date of birth, sex and location which we will then use to form a Guardian identity. You may use your picture from Google as part of your profile. This also allows us to share your networks, user ID and any other information you choose to share according to your Google account settings. If you remove the Guardian from your Google settings, we will no longer have access to this information.

If you log-in to our sites using a twitter log-in, we receive your avatar (the small picture that appears next to your tweets) and twitter username.

Children’s Online Privacy Protection Act Compliance

We are in compliance with the requirements of COPPA (Childrens Online Privacy Protection Act), we do not collect any information from anyone under 13 years of age. Our website, products and services are all directed to people who are at least 13 years old or older.

Updating your personal information

We offer a ‘My details’ page (also known as Dashboard), where you can update your personal information at any time, and change your marketing preferences. You can get to this page from most pages on the site – simply click on the ‘My details’ link at the top of the screen when you are signed in.

Online Privacy Policy Only

This online privacy policy applies only to information collected through our website and not to information collected offline.

Your Consent

By using our site, you consent to our privacy policy.

Changes to our Privacy Policy

If we decide to change our privacy policy, we will post those changes on this page.


                            

                        


                        Save settings

						                    

                

            

			                

                    

                        Cookies settings
                    

                

				

Seamless Theme Keith, made by Altervista
Create a website and earn with Altervista - Disclaimer - Report Abuse - Privacy Policy - Customize advertising tracking