Let's now take a look at how you create and manage an OSS bucket. So, I'm here on the alibabacloud.com homepage. I'm going to go over and click on Console. And then we'll go over to the OSS console. So right now I'm on the Alibaba Cloud Console Homepage. From here I need to navigate over to OSS. So how do I do that? Well, I take my mouse and I mouse over to this orange and white Menu button here. A menu will pop out from your left-hand side with Products and Services at the top. When I mouse over that, a search bar will open up as well as a product list, listing all of the products currently available on the alibabacloud.com website, and I'll type in OSS to search for and locate Optic Storage Service.

When I click on that, I'll be directed to the OSS console. And you can see, unlike the ECS console, the bucket list and the overview page in OSS are both global. So there's no regional selection up here. All your buckets, no matter where they are in the world, are all listed in one place. And you can see that the region in which the bucket is located is one of the items here in the bucket overview list, so you can get an idea where your buckets are located. In fact, you can even sort by region, by storage class and by bucket name if you want to make this list a little bit easier to navigate.

So let's go ahead and create a new bucket. So I'll click on Create Bucket, that will open up a menu where I can choose a bucket name. Remember, your bucket name has to be globally unique, so I'm going to try to choose a name that nobody else has chosen. Once I do type in a name, the service will tell me whether or not it's taken. You can see here after I've typed in jdp, the service indicates that this bucket already exists or is in used by another user, so I can't take that name. So I'll call it jdp-test-bucket, which should be okay. Yep, that's not taken. And I'm going to use Singapore as my region. And you'll note that here, I can choose my storage class, this is the default storage class for the bucket. I can choose either Standard, Infrequent Access or Archive from here.

In my case, I will stick with the default of Standard. That means any objects I add to the bucket will have the storage class, Standard. They'll use this Standard OSS storage class. If I want, I can have some of the objects in the bucket live within a different storage class. There's no rule that all of the objects must be in the same storage class. Objects within a given bucket can be in different storage classes. That's not an issue. In fact, when I can figure life cycle policy for the objects in my bucket, a natural result of that will be that when objects reach a certain age, they will be moved to another storage class. So I might have some objects in my bucket that were recently added still in the Standard class, and some objects in the Infrequent Access or Archive class instead.

In my case for the demo, I'll just be keeping everything in Standard. I can turn on Zone-redundant Storage if I want. Again, this gives me better durability and availability by spreading the copies of my data in OSS across multiple zones within a single region. I will leave that disabled, but if I wanted to, I could turn that on. Versioning, again, if you upload a new copy of an existing object to your bucket, with Versioning disabled, the new copy will overwrite the old copy of the object. The old copy of the object will be lost. However, if I turn on Versioning, then when I upload a new copy of an existing object, the old copy is kept in the background and tagged with a version number.

In this way, I can build up a version history for the objects I'm uploading into my OSS bucket, and I can restore or revert to one of those old versions of the object later if I want. This is an especially valuable feature if you're using your OSS bucket maybe to store code, or maybe to store Terraform files, or something where you want the ability to go back in time and potentially restore an old version. Access control. There are three types of ACL for buckets, private, public read, and public read/write. So with private, all requests, either to access an object, or to update or upload a new object, must be signed. So with private ACL set, every request I make to the OSS service has to be signed, proving that I have permission to access this bucket, that I'm a member of this Alibaba Cloud account.

With public read, requests to upload or write data into the bucket must be signed with a STS token, but requests to read can be anonymous. So if I set my bucket as public read, I can easily take the URLs for the objects in the bucket and say, embed them into the HTML for a webpage. And then when a user's browser loads that page and request those resources, it will directly be granted access rather than having to sign the request with an Alibaba Cloud Key. Public read/write does the same thing, except reading, deleting and writing objects is all allowed anonymously. This is quite dangerous. I don't recommend that you use public read/write in practice.

Public read is appropriate for some types of website or web application. But for the most part, you should stick with the default and use private here. Encryption, again, there's two types. OSS-managed, this uses the AES256 key that's built into the OSS service. And then there's KMS, which uses a key that you've created yourself inside of our Key Management Service. I'll choose none for this demo. I won't enable encryption at all. If I'd like, I can set up a scheduled regular backup of the content of my OSS bucket. I can use our Hybrid Backup Recovery, HBR, service to do this, and that will take regular snapshots of my bucket. I'm going to leave that disabled, but I will turn on Real-time Log Query.

So what Real-time Log Query does is it allows me to search through a full text index or archive of all the log events that have happened after I've set up my bucket. So when someone adds a new object or makes a request, I can see all that information via the Log Query window. Okay. So let's click OK, and create our bucket. So after waiting a second, our bucket is now ready to go. You can see it's empty right now. No requests this month. Zero bytes of traffic. Zero storage use. I can get some basic information here about the configuration of the bucket, and I can change configuration for any of these by clicking on configure. Same thing for these, for instance, if I want to enable ordinary logging, which backs up logs to another OSS bucket, I can do that. I've already got real-time logging turned on, so I'm not going to turn that on.

Life cycle, I can configure that. I can create a rule here that will say, move objects that are older than 60 days to IA storage. And then I can click OK, and then we'll say, we'll delete objects older than 180 days. You can also choose to delete an object as well. So I'll say, OK. And now objects at 60 days get moved to IA, and 180 days, they get deleted automatically. So now I have life cycle rules set up, and these rules will take effect within 48 hours of having them created. So I do have to wait a little bit for those rules to take effect. Now let's go ahead and upload some objects to our bucket.

So I will upload maybe a picture. So let's go to my Downloads folder, and I will choose from the Images folder this bunny, and I'll click Open. And now I've uploaded this bunny. I can now click on Removed to clear this upload task list. Don't worry that doesn't delete the object. It just clears out this task list. And then here's my bunny object. Great. That's it. That's how you set up and manage a bucket. For additional settings, you can look in Access Control. This lets you set Bucket Policy, set Access Control Lists, determine what RAM roles are allowed to access the bucket, and turn on Cross-Origin Resource Sharing or Hotlink Protection, which is especially useful if you are using your OSS bucket to host web content, and you only want certain sites to be allowed to link to that content.

Bucket policy, let's have a quick example. If I click Configure and I click Authorize, I can start creating policies. I can apply them to specific resources within the bucket or to the whole bucket. And I can make the policy apply to RAM user accounts, other Alibaba Cloud accounts, or anonymous accounts. And what I can do is decide what operations are authorized, and under what conditions. So for instance, if I were to make the whole bucket read/write for an anonymous account from a particular IP, then when I access the service from that IP, I do not need to sign my requests. I'll be allowed to anonymously access all of the items in the bucket, and also read, write and delete those items all without proving my authentication or identity, just because I'm coming from this IP address. If I came from some other IP address, then I would be asked for an STS token to authenticate me.

Okay. And one other thing we should look at, Basic Settings. Here I can adjust server-side encryption settings, set up static web hosting, set up bucket lifecycle. I can tag my bucket, which makes it easier to sort my buckets, and also read my bill. I can set up Back-to-Origin, which will fetch objects from some other web address if an object is not found in the bucket. You can use this as a way to do transparent mirroring of some origin site. I can trigger notifications when certain operations are performed, so that I can track access to my bucket. And I can also turn on what's called Pay by Requester, which is where the person requesting the object or objects from my bucket has to pay for my network bandwidth. So the data and the traffic fees are charged to that other person.

Obviously, in order to configure that, the other person needs to have an Alibaba Cloud account. And then I can set up a retention policy as well, which will allow me to configure what we call WORM, or write once read many, which means I can set up a bucket for compliance in which it's impossible to delete objects before a certain timeframe has passed. This is a great way to enable very solid hack-proof auditing. And then I can also do something called Bucket Inventory, which will create an inventory list of the objects in my buckets, which is great for auditing and verification. And then the final setting, I can delete my bucket. But before we do that, now that we've got a file in here, let's try visiting it and then let's see what logs were generated. So I'll click on bunny.jpg. Here we go. Copy file URL. And you can see it's got a time limited access key or sign-in key built into the URL here. That key is valid for 300 seconds.

When I copy the file URL and paste it into a new tab, the image loads. And if I were to wait 300 seconds, this URL would become invalid because the time for this, the time to live for this key would have passed. So let's see if I can see that access request in the logs. So let's go down to Logging, and we'll go to Real-time Log Query. And here we have a nice Dashboard where we can see the last seven days worth of logs. And you can see currently, there's a few requests showing up already. This isn't quite in real time, but it's close. 

Let's take a look at this one here. So 16 occurrences. Let's see what happened. So this is probably our access requests. Let's click on that and take a look. So what we're looking for is a GET request. So let's take a look for http_method_GET, and you can see that we attempted to access what? This bunny object. And sure enough this is the sign-in key we used. And we can see some information about the time that the access took place, the IP address, where you can see the result, access denied or successful. And we can see the user agent, so you can tell that I actually tried to access this item from a browser on a Mac. So you can get a lot of information out of the Logging Dashboard that's built-in when you turn on Real-time Log Query. And that's it for this demo.