Запуск собственного кода на Azure

Я пытаюсь запустить исполняемый файл C на Azure. У меня много рабочих ролей, и они постоянно проверяют очередь заданий. Если в очереди есть задание, рабочая роль запускает экземпляр исполняемого файла C как процесс в соответствии с аргументами командной строки, хранящимися в классе задания. Исполняемый файл C обычно создает некоторые файлы журналов. Я не знаю, как получить доступ к этим созданным файлам. Какова его логика? Где хранятся созданные файлы? Может ли кто-нибудь объяснить мне? Я новичок в azure и С#.

Еще одна проблема заключается в том, что всем рабочим экземплярам исполняемого файла C необходимо прочитать файл данных. Как я могу распространять этот файл?

Ответ 1

Во-первых, поймите, что в Windows Azure ваша рабочая роль просто выполняется внутри среды Windows 2008 Server (SP2 или R2). При развертывании приложения вы также развертываете исполняемый файл C (или захватываете его из хранилища blob, но немного более продвинутым). Чтобы узнать, где ваше приложение живет на диске, вызовите Environment.GetEnvironmentVariable("RoleRoot") -, который возвращает путь. Обычно у вас есть приложение, находящееся в папке с именем AppRoot под корнем роли. Вы найдете там свой исполняемый файл C.

Затем вам нужно, чтобы ваше приложение записывало свои файлы в выходной каталог, указанный в командной строке. Вы можете настроить хранилище в своей локальной виртуальной машине с вашими свойствами роли. Перейдите на вкладку "Локальное хранилище" и настройте именованную область хранения:

enter image description here

Теперь вы можете получить путь к этой области хранения, в коде и передать ее в качестве аргумента командной строки:

var outputStorage = RoleEnvironment.GetLocalResource("MyLocalStorage");
var outputFile = Path.Combine(outputStorage.RootPath, "myoutput.txt");
var cmdline = String.Format("--output {0}", outputFile);

Вот пример запуска процесса myapp.exe с аргументами командной строки:

var appRoot = Path.Combine(Environment.GetEnvironmentVariable("RoleRoot")
            + @"\", @"approot");

var myProcess = new Process()
{
   StartInfo = new ProcessStartInfo(Path.Combine(appRoot, @"myapp.exe"), cmdline)
   {
      CreateNoWindow = false,
      UseShellExecute = false,
      WorkingDirectory = appRoot
   }
};
myProcess.WaitForExit();

Обычно вы устанавливаете CreateNoWindow в true, но его легче отлаживать, если вы можете увидеть окно командной оболочки.

Последнее: после того, как ваше приложение будет создано для создания файла, вы также захотите:

  • Обработайте его и удалите (он не в прочном месте, так что в конце концов он исчезнет)
  • Измените хранилище, чтобы использовать Cloud Drive (долговечное хранилище)
  • Скопируйте файл в blob (долговечное хранилище)

В процессе производства вы захотите добавить обработку исключений, и вы можете перенаправить stdout и stderr для захвата. Но этот примерный код должен быть достаточно, чтобы вы начали.

OOPS - еще одна вещь: "Добавляя" myapp.exe "в свой проект, будьте уверены, чтобы перейти к его свойствам и установить" Копировать в выходной каталог "на" Копировать всегда "- в противном случае ваш myapp.exe файл не окажется в Windows Azure, и вы будете удивляться, почему все не работает.

EDIT: нажатие результатов на blob - быстрый пример

Сначала настройте учетную запись хранилища и добавьте в свою настройку роли. Скажем, вы назвали его "AzureStorage" - теперь настройте его в коде, получите ссылку на контейнер blob, получите ссылку на blob внутри этого контейнера, а затем выполните загрузку файла в blob:

        CloudStorageAccount storageAccount = CloudStorageAccount.FromConfigurationSetting("AzureStorage");
        CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
        CloudBlobContainer outputfiles = blobClient.GetContainerReference("outputfiles");
        outputfiles.CreateIfNotExist();

        var blobname =  "myoutput.txt";
        var blob = outputfiles.GetBlobReference(blobname);
        blob.UploadFile(outputFile);

Ответ 2

На лазурной земле вы не должны писать в файловую систему. Вы должны написать SQL Azure, Table Storage или, скорее всего, в этом случае хранилище Blob (в основном, я думаю, вы должны думать о хранилище blob как о старой файловой системе)

Это происходит потому, что:

  • У вас может быть несколько запущенных экземпляров, и у вас будут разные файлы на разных экземплярах (которые являются только виртуальными машинами).

  • Ваш экземпляр потенциально может быть перемещен в любой момент, и вы потеряете информацию в файловой системе, так как она не входит в пакет развертывания.

Использование одной из трех опций хранилища обеспечит центральный репозиторий для всех ваших экземпляров для доступа, и он будет сохраняться в результате перераспределения.