When migrate your application onto the Azure one
of the biggest concern would be the external files. In the original way we understood and ensure which machine and folder our application (website or web service) is located in. So that we can use the MapPath or some other methods to read and write the external files for example the images, text files or the xml files, etc. But things have been changed when we deploy them on Azure. Azure is not a server, or a single machine, it’s a set
of virtual server machine running under the Azure OS. And even worse, your application might be moved between thses machines. So it’s impossible to read or write the external files on Azure. In order to resolve this issue the Windows Azure provides another storage serviec – Blob, for us. Different to the table service, the blob serivce is to be used to store text and binary data rather than the structured data. It provides two types
of blobs: Block Blobs and Page Blobs. Block Blobs are optimized for streaming. They are comprised
of blocks, each
of which is identified by a block ID and each block can be a
maximum of 4 MB in size. Page Blobs are are optimized for random read/write operations and provide the ability to write to a range
of bytes in a blob. They are a collection
of pages. The
maximum size for a page blob is 1 TB. In the managed library the Azure SDK allows us to communicate with the blobs through these classes CloudBlobClient, CloudBlobContainer, CloudBlockBlob and the CloudPageBlob. Similar with the table service managed library, the CloudBlobClient allows us to reach the blob service by passing our storage account information and also responsible for creating the blob container is not exist. Then from the CloudBlobContainer we can save or load the block blobs and page blobs into the CloudBlockBlob and the CloudPageBlob classes. Let’s improve our exmaple in the previous posts – add a service method allows the user to upload the logo image. In the server side I created a method name UploadLogo with 2 parameters: email and image. Then I created the storage account from the config file. I also add the validation to ensure that the email passed in is valid. 1: var storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
2: var accountContext = new DynamicDataContext<Account>(storageAccount);
3:
4: // validation
5: var accountNumber = accountContext.Load()
6: .Where(a => a.Email == email)
7: .ToList()
8: .Count;
9: if (accountNumber <= 0)
10: {
11: throw new ApplicationException(string.Format("Cannot find the account with the email {0}.", email));
12: }
Then there are three steps for saving the image into the blob service. First alike the table service I created the container with a unique name and create it if it’s not exist.
1: // create the blob container for account logos if not exist
2: CloudBlobClient blobStorage = storageAccount.CreateCloudBlobClient();
3: CloudBlobContainer container = blobStorage.GetContainerReference("account-logo");
4: container.CreateIfNotExist();
Then, since in this example I will just send the blob access URL back to the client so I need to open the read permission on that container.
1: // configure blob container for public access
2: BlobContainerPermissions permissions = container.GetPermissions();
3: permissions.PublicAccess = BlobContainerPublicAccessType.Container;
4: container.SetPermissions(permissions);
And at the end I combine the blob resource name from the input file name and Guid, and then save it to the block blob by using the UploadByteArray method. Finally I returned the URL
of this blob back to the client side.
1: // save the blob into the blob service
2: string uniqueBlobName = string.Format("{0}_{1}.jpg", email, Guid.NewGuid().ToString());
3: CloudBlockBlob blob = container.GetBlockBlobReference(uniqueBlobName);
4: blob.UploadByteArray(image);
5:
6: return blob.Uri.ToString();
Let’s update a bit on the client side application and see the result. Here I just use my simple console application to let the user input the email and the file name
of the image. If it’s OK it will show the URL
of the blob on the server side so that we can see it through the web browser.
Then we can see the logo I’ve just uploaded through the URL here.
You may notice that the blob URL was based on the container name and the blob unique name. In the document
of the Azure SDK there’s a page for the rule
of naming them, but I think the simple rule would be – they must be valid as an URL address. So that you cannot name the container with dot or slash as it will break the ADO.Data Service routing rule. For exmaple if you named the blob container as Account.Logo then it will throw an exception says 400 Bad Request.
Summary
In this short entity I covered the simple usage
of the blob service to save the images onto Azure. Since the Azure platform does not support the file system we have to migrate our code for reading/writing files to the blob service before deploy it to Azure.
In order to reducing this effort Microsoft provided a new approch named Drive, which allows us read and write the NTFS files just likes what we did before. It’s built up on the blob serivce but more properly for files accessing. I will discuss more about it in the next post.
Hope this helps,
Shaun
All documents and related graphics, codes are provided "AS IS" without warranty
of any kind.
Copyright © Shaun Ziyan Xu. This work is licensed under the Creative Commons License.
